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ABSTRACT 


Unmanned tactical autonomous control and collaboration (UTACC) is a Marine 
Corps experimental research initiative with the overarching aim of developing a 
collaborative human-robotic system of systems (SoS). This thesis analyzed the results of 
the existing UTACC concept development and incorporated them into an emergent 
human-robotic system development method, Coactive Design. An advantage to using this 
method is that it includes the human and his or her internal processes when modeling the 
system. As such, the focus is shifted to supplementing team capacities vice developing 
autonomy. 

The two aims of this thesis are (1) to provide a recommendation for incorporating 
the Coactive Design method into the systems’ development life cycle and (2) to provide a 
list of design requirements for a resilient UTACC SoS. Resilience is realized by 
designing for flexibility. A teamwork infrastructure built on many interdependent 
relationships provides this flexibility. These interdependent relationships can be grouped 
into three areas: observability, predictability, and directability. Counter to conventional 
practices within the robotics industry. Coactive Design focuses on managing these 
interdependencies rather than focusing on autonomy. Coactive Design also provides a 
cost-benefit analysis of development choices, which assists with developing efficiencies 
during the design and development of the system. 
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EXECUTIVE SUMMARY 


This thesis is part of an ongoing initiative to support the Unmanned Tactical 
Autonomous Control and Collaboration (UTACC) effort sponsored by the Marine Corps 
Warfighting Laboratory (MCWL). UTACC is being designed as a system of systems 
(SoS) that includes autonomous air and ground components geared to provide 
intelligence, surveillance, and reconnaissance (ISR) for support of Marine Corps tactical 
units. What separates UTACC from other such systems is the collaborative nature of the 
interdependent human-machine (H-M) team. The UTACC system is being developed 
through an iterative and incremental design process as a means of satisfying the need for 
exploratory, technological research called for in the Marine Corps’ current, strategic and 
visionary planning document. Expeditionary Force 21. 

UTACC completed its initial concept development in 2015 and immediately set 
about defining requirements to support those concepts. The search for a methodology that 
could assist with accurately capturing these requirements and relationships that support 
them became a critical investment and one of the aims of this thesis. The Coactive Design 
method was chosen for analysis of any potential UTACC suitability due to the acclaim 
for the method’s architect. Dr. Matthew Johnson, from the 2013 Defense Advanced 
Research Projects Agency’s (DARPA) Virtual Robotics Challenge (VRC) and the 2015 
DARPA Robotics Challenge (DRC). Coactive Design is an emergent H-M design method 
that helps decipher high-level teaming concepts into reusable and programmable controls, 
interface components, and behaviors that allow machines to act as teammates. 

Coactive Design is based on the concept of interdependence among humans and 
machines operating as a team in order to accomplish a mission. These coactively 
designed interdependencies are broken down into three categories: observability, 
predictability, and directability. This interdependence framework runs counter to the 
conventional H-M system design wisdom, which seeks to increase levels of system 
autonomy or human independent actions. The Interdependence Analysis (lA) Tables are 
the tool that Coactive Design uses to generate system requirements. The tables 

decompose tasks into the most elemental capacities required in order for these tasks to be 
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performed. After task decomposition, each individual capacity is studied within the 
context of the H-M relationships and requirements are then derived that help support 
those relationships. 

This thesis’s research has had several impact areas on the UTACC initiative. First, 
Coactive Design provides UTACC a list of detailed system design requirements. Second, 
Coactive Design offers UTACC a means of achieving a resilient system by designing 
alternate pathways for recognizing and managing uncertainty. These pathways were 
realized as a result of the analysis conducted using the lA Tables, and provide the H-M 
team flexibility in the way the team approaches the tasks and how the team adapts to 
problems in tactical situations. Third, this thesis provides recommendations on which 
capacities UTACC should focus on, given its limited developmental time and resources. 
As was the case with the system flexibility provided through alternative teaming 
pathways, the design and development efficiencies are also a direct byproduct of the lA 
Table analysis. Lastly, the UTACC specific Coactive Design has the added benefit of 
fusing and preserving several preceding UTACC efforts. For these reasons, the author 
recommends incorporating Coactive Design into the entire development life cycle for 
UTACC, and suggests that this design method be considered for all of the Marine Corps’ 
future H-M system development projects. 
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I. 


INTRODUCTION 


This thesis is part of an ongoing initiative to support the Unmanned Tactical 
Control and Collaboration (UTACC) effort sponsored by the Marine Corps Warfighting 
Laboratory (MCWL). The UTACC system is being developed through an iterative and 
incremental design process. As such, similarities exist between this work and that 
conducted both previously and in parallel. This thesis expands and utilizes many of the 
results and products developed under previous Naval Postgraduate School UTACC 
theses. The results of these authors’ works were used to develop concurrent work for 
other such theses. 

A. SPONSORING COMMAND, OBJECTIVE, AND RESULTS 

MCWL is the parent command for the experimental UTACC initiative. The 
UTACC system is being designed as a system of systems (SoS) that includes autonomous 
air and ground components geared to provide intelligence, surveillance, and 
reconnaissance (ISR) for support of Marine Corps tactical units. The intent behind this 
thesis is to develop requirements for the interface that allows the human component of 
the UTACC team to communicate with the robotic elements and vice versa. These 
requirements will offer the system’s engineers vital Marine Corps user perspective that 
will aid in the speed and ease of adopting the system at the user level. In their book. 
Switch, Chip and Dan Heath discussed organizational change to stress the importance of 
why soliciting and building user preferences from the beginning of the design and 
development phase is important for enterprise-level adoption during transformational 
change periods (2010). 

The author has operational experience with Marine Corps unmanned aerial and 
ground systems; however, the author is not familiar with the UTACC proposed level of 
autonomy and collaborative capabilities. This operational experience will serve as an 
initial litmus test for use case development and will also provide user perspective, a key 
ingredient for interface design. These interface design requirements will be derived from 
Marine Corps tactics, techniques, and procedures, as well as. Marine Corps doctrinal and 
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warfighting publications in order to ensure continued relevancy to the Marine Corps in 
the future. 

B. RETURN ON INVESTMENT TO MARINE CORPS WARFIGHTING LAB 

As technology continues to rapidly advance, the UTACC system offers the 
Marine Corps the opportunity to expand its capabilities, controlling the pace with which 
advanced autonomous robotics are incorporated into warfare. The coactive design 
methodology and tools are invaluable to UTACC’s design process. Coactive design helps 
decipher high level teaming concepts into reusable and programmable controls, interface 
components, and behaviors that allow machines to act as teammates (Johnson, 2014). 
Within the UTACC construct, the defining of the interdependent relationships between 
human and machines provides MCWL with another critical payoff. This paradigm shift 
from dependent to interdependent relationships, along with an in-depth understanding of 
what interdependence means, comprises a revolution within the robotic design and 
development disciplines. Those who use this concept as the crux of their design 
framework are rewarded with an empirical competitive advantage in the form of 
increased observability, predictability, and directability between Marines and unmanned 
components. 

C. RESEARCH METHODOLOGY OVERVIEW 

As a small portion of the UTACC initiative, this thesis utilizes concepts from 
command, control, communications, computers, and intelligence (C4I) literature for 
building the requirements of the UTACC system. The requirements are built from the 
concept design conducted in Rice’s, Keim’s, and Chhabra’s (2015) UTACC thesis work. 
The core of the Rice et al.’s (2015) work came in the form of MCWL-approved task 
analysis worksheets. These worksheets built upon the Marine Corps Troop Leading 
Steps, BAMCIS: begin the planning, arrange for reconnaissance, make reconnaissance, 
complete the plan, issue the order, and supervise (USMC, 2002). All Marines are taught 
this planning process during their basic training, and it serves as a fundamental building 
block within the Marine Corps user perspective. This thesis aims to provide the system 
designers and engineers such a perspective. 
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The task analysis worksheets were studied by the author and morphed into a more 
easily digestible form by the interdependence analysis (lA) tables, derived from those 
found in Johnson’s (2014) doctoral thesis on Coactive Design. lA tables break down 
complex tasks into their most elemental sub-tasks and further to capacities required to 
complete the job. Once all of the worksheets were imported into the IA tables, the author 
refined and filled in gaps that were not identified by the Rice et al. (2015) team but were 
essential to the accomplishment of the overarching tasks they proposed. Then, each 
individual capacity was analyzed against all viable teaming role alternatives (e.g., robot 
or human) to see which was more capable of filling the requirement and to what extent 
the other teammates were able to assist. In this way, the interdependent relationships of 
the teammates were mapped out. The author then extrapolated requirements for the 
System-Marine interfaces that will serve to enable these interdependent relationships. 

D. RELATED WORK 

This thesis complements other theses conducted in the UTACC program. Rice, 
Keim, and Chhabra (2015) and Batson and Wimmer (2015) were the predecessors of this 
thesis work and formed the foundation of this thesis. The work of Kirkpatrick and 
Rushing is in progress at the time of this writing and focuses on mapping the 
requirements also identified in this thesis to measures of performance (MOPs) and 
measures of effectiveness (MOEs). The work of Larreur is also in progress and focuses 
on establishing a roadmap of experimentation to validate the requirements of this thesis 
and evaluate the MOPs and MOEs suggested in Kirkpatrick’s and Rushing’s work. 

Johnson’s (2014) work and preceding publications on interdependence, 
autonomy, and especially Coactive Design were of critical importance to this thesis. 
Johnson (2014) developed the Coactive Design model and interdependence analysis 
tables for use within a single human-single machine teaming environment that this author 
modified to the many humans-many machines environment unique to UTACC. 

E. NEED FOR COACTIVE DESIGN WITHIN UTACC 

Coactive Design offers MCWE a methodical, efficient, and user centric iterative 

process for building UTACC. It is a method for designing interdependent systems that 
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uses a design tool called an interdependence analysis table, which details human-machine 
requirements. The requirements guide implementation of the system, providing teamwork 
infrastructure. The accumulation of all the capabilities under the teamwork infrastructure 
determines the runtime options, which determine performance (Johnson, 2014). The 
flexibility provided by these options will equate to a vastly resilient UTACC system. 

F. CHAPTER SUMMARY 

This chapter has provided a broad overview of UTACC and described why the 
program is necessary within the backdrop of the Marine Corps’ Expeditionary Force 21 
(EF21). As a result of this necessity, MCWE, as the sponsoring unit for this program, 
serves to benefit by continuing to invest with UTACC. MCWE’s ROI will see 
improvements in both time to market and user acceptance if Coactive Design is adopted 
into the development life cycle of this program. Furthermore, this thesis offers the dual 
benefit of preserving the previous UTACC research efforts and in guiding parallel efforts. 
The most important product from this thesis is the list of system and user interface 
requirements, which were derived from the Coactive Design research methodology. 

This UTACC specific Coactive Design merges several preceding works. The 
most influential of those efforts being the work of Johnson (2014), a revolution within 
human-machine teaming, and that of Rice et al. (2015), the UTACC concept 
development team. The next chapter explores these works in greater detail. 
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II. LITERATURE REVIEW 


A. UNMANNED TACTICAL CONTROL AND COLLABORATION 

Unmanned Tactical Control and Collaboration (UTACC) is a developing research 
effort concerned with human and machine teaming within the backdrop of the United 
States Marine Corps. The tactical application of UTACC is of interest to the Marine 
Corps Warfighting Laboratory (MCWL) as it explores the stated need for innovative and 
exploratory technological research called for in Expeditionary Force 21 (EF21). EF21 
(2014) serves as the Marine Corps’ current strategic and visionary planning tool that will 
help shape the force of the future. The Marine Corps Combat Development Command 
(MCCDC) recognizes that many of the initiatives with potential value offerings are not 
fully mature yet (MCCDC, 2014). However, MCCDC (2014) requires deliverables that 
aid in the development of future force capabilities. The UTACC coactive design products 
within this paper and paralleling, complementary research, if certified by MCWL, qualify 
for these future force capability shaping deliverables. 

Military technology advances in the unmanned systems arena provide new 
capabilities while outsourcing current human performed tasks. This next generation of 
warfare research is aimed at lessening the cognitive load of humans as the interactions 
between humans and machines become more complex. To this end. Rice, Keim, and 
Chhabra (2015) identified the user interface as one of the most significant pieces of the 
UTACC system, as it bridges the gap between constantly evolving robotic agents and the 
humans that they must work with. This thesis further develops such previous UTACC 
research efforts. It proposes interface and systems design requirements that aim to bring 
these UTACC concepts to life. The design requirements are the direct result of the 
application of the coactive design method. Johnson’s (2014) doctoral thesis proposed the 
coactive design process as a new approach to dissecting the nuanced interdependencies 
between humans and machines engaged in joint activity. This design process makes it 
possible for high-level concepts like collaboration and teamwork to be translated into 
requirements implementable through algorithms and programming behavioral logic. 
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B. UTACC VISION AND OVERVIEW 


MCWL signed a FY14 statement of work (SOW) that proposed tasks for UTACC 
to conduct over the following three years; the end state being the production of a 
“decision-centric, semi-autonomous, distributive, multi-agent, multi-domain robotic 
system” (Statement of Work [SOW], 2014, p. 1). In order to accomplish this, UTACC 
leverages collaborative autonomy to significantly reduce operator interaction with robotic 
systems while not limiting the system’s ability, thus improving human performance and 
promoting mission success. Under the SOW (2014), the UTACC system encompasses 
both semi-autonomous unmanned ground and air vehicles in addition to the human 
element. 

Developed with a modular system of systems (SoS) approach, UTACC is 
designed to be scalable and adapt over time to encompass additional missions, adapt to 
new conditions, and rise to evolving threats (SOW, 2014). A reconnaissance mission was 
chosen as the initial frame of reference for building out the initial UTACC concept 
development. Within this single Marine Corps mission a small tactical team of four 
Marines, commonly referred to as a fire team, would serve as the human element within 
the greater UTACC construct (Rice et ah, 2015). 

C. EXPEDITIONARY FORCE 21 

Published in March 2014, EF21 serves as the Marine Corps’ new capstone 
concept, having replaced the Marine Corps Vision and Strategy 2025. It promotes plans, 
aligns future concepts and creates capability roadmaps (EF21, 2014). Part of the modem 
force attributes described within EF21 (2014) is the ability to exploit innovative concepts 
and methods allowing the Marine Corps to maintain its decisive edge over adversaries. 
UTACC offers to sharpen that edge through increased fidelity in planning coupled with 
the reduction in workload for the human operators during critical periods of the mission. 
Furthermore, UTACC seeks to leverage the Marine Corps traditional operating practices 
while building this SoS, with the users in mind from the very inception. 

Marine Corps Warfighting and Doctrinal Publications (MCWPs and MCDPs) 
reinforce the concept and interface design processes. Gathering requirements from 
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Marine Corps missions, strategic vision, and publications allows for ease of integration 
and employment of the system of systems (SoS). This development method is initially 
more time intensive than adopting civil technologies within similar enterprises (Bernard, 
2012). However, it does offer a more effective implementation plan than incorporating 
the requirements at the end of development (Bernard, 2012). 

EF21 (2014) called for the Marine Corps to relentlessly pursue its return on 
investment across the enterprise while seeking these innovative approaches to capability 
development. The results of this thesis achieve this for UTACC; the main outputs provide 
system designers with tailored requirements for the system interface. It has also allowed 
other complementary research to continue in parallel, such as research supporting 
measures of performance and measures of effectiveness (MOPs and MOEs). The forward 
deployed posture that EF21 envisions projects one-third of the operating forces aboard. 
The final UTACC SoS offers the potential to redefine the Marine Corps enterprise. These 
could be realized in reductions to manning and the task organization of infantry battalions 
and company landing teams, the Marine Corps’ standard deployment unit capable of 
securing landing sites or maneuvering to deep inland objectives during entry operations 
(EF21, 2014). These discussions will serve as areas requiring future research. 

D. UTACC CONCEPT OF OPERATIONS 

UTACC Concept of Operations, or concept design, was the thesis work of Rice, 
Keim, and Chhabra (2015), which set the stage for all follow on work within UTACC. It 
fits within the systems analysis and design process described by Satzinger, Jackson, and 
Burd (2012), which is where this thesis continues. Specifically, Rice et al.’s (2015) 
research captured the system requirements, logical sequencing of operational activities, 
and developed a model for mission planning and execution. Without these three 
functional areas, the UTACC coactive design model would not have been possible. A 
summary of these functional areas follows. 

1. UTACC System Requirements 

The SOW (2014) provides MCWE’s endorsement of Rice et al.’s (2015) 

constraints for the final system’s capabilities. They are summarized as: 
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• Adaptive behaviors providing reduced operator workload 

• Collaborative command and control 

• Distributive and modular architectural infrastructure 

• Distributive processing and storage 

• Organic mapping and obstacle avoidance 

• Autonomous system diagnostics 

• Ease of maintenance 

• Organic power operation (SOW, 2014, pg. 2) 

Reducing the current workload of the humans in the team is central to the 
fundamental purpose of UTACC. Tangent to this constraint is the ability of all components 
to collaborate their individual sensing and collecting capabilities. An integrated system 
interface provides the means to communicate this information back and forth between 
human and robot. Distributing functionality and making components modular allows the 
system to continue the mission should a single component be removed from the task. The 
UTACC system must be able to map its surroundings and avoid obstacles as it moves 
throughout the battlespace while collecting and sensing. Each system element must monitor 
its sensors’ health, communication links to the team, and fuel status. Due to the 
expeditionary nature of these small tactical teams, the elements must be durable, allow for 
basic field maintenance, and must operate under their own power. 

2. Sequence of Operational Activities 

Rice et al. (2015) adapted the Marine Corps’ troop-leading steps: begin planning; 
arrange for reconnaissance; make reconnaissance; complete the plan; issue the order; and 
supervise activities (BAMCIS) as the groundwork for building the functional UTACC 
model. These steps are important to the UTACC coactive design process because they 
serve as the highest level of organization within the UTACC coactive design model. The 
following quote from the Marine Rifle Squad (USMC, 2002) publication defines 
BAMCIS as: 
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The troop-leading procedures listed below are aids in preparing for and 
executing assigned missions. They assist squad and fire team leaders in 
making the best use of time, facilities, and personnel. All the steps should 
be considered, but depending upon the mission and time available, the 
degree of consideration for each will vary. 

Begin Planning. When an order is received, the squad leader considers the 
time available to him. In so doing, he uses a planning sequence called 
reverse planning, meaning that he starts with the last action for which a 
time is specified (e.g., an attack) and works backward to the issuing of his 
order. This helps ensure that enough time is allowed for the completion of 
all necessary actions. During this stage, he also analyzes the terrain and 
the friendly and enemy situation. From his analysis, he formulates a 
preliminary plan of action to accomplish the mission. This plan is only 
tentative and will often be changed. 

Arrange for Reconnaissance and Coordination. The squad leader selects a 
route and prepares a schedule for reconnaissance and coordination with 
adjacent and supporting units. Normally, he takes his fire team leaders and 
the leaders of any attached crew-served weapons teams with him on his 
reconnaissance. 

Make Reconnaissance. On his reconnaissance, the squad leader completes 
his estimate of the situation. Prearranged meetings with adjacent squads 
and supporting units are held as scheduled. He notes how the terrain 
affects his preliminary plan and adopts, alters, or ejects it as necessary. 

While on his reconnaissance, he selects advantage point from which to 
orient his fire team leaders. 

Complete Plan. Upon his return from the reconnaissance, the squad leader 
completes his plan of action. He then prepares notes to be used in issuing 
his order. 

Issue Order. If possible, the squad leader issues his order to the same 
personnel he took with him on his reconnaissance from the vantage point 
he had selected earlier. If this is not possible, the team leaders are oriented 
from maps, sketches, or an improvised terrain model. He issues his order 
using the five-paragraph order sequence and includes everything his fire 
team and attached weapons leaders need to know. 

Supervise Activities. The squad leader continuously supervises his unit to 
ensure that his order is carried out as intended. (2002, pp. C1-C2) 

These steps form a logical sequence of iterative events that allow Marines to 
conduct all pre-mission activities while ensuring a high likelihood of success during the 
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execution phase. The BAMCIS process is uniquely suited for implementation as the 
backbone of the UTACC concept of operations due to the close familiarity that all 
Marines have with it. Figure 1 is a graphical depiction of these concepts. 


Figure 1. Marine Corps Troop-Leading Steps (BAMCIS) 



Source: Rice, T., Keim, E. A., Chhabra, T. (2015). Unmanned tactical autonomous 
control and collaboration concept of operations. (Master’s thesis). Naval Postgraduate 
School. Retrieved from Calhoun http://calhoun.nps.edu/handle/10945/47319. 


3. Mission Planning and Execution Model 

With these human centric procedures in mind, Rice et al. (2015) explored 
incorporating the machine aspects of UTACC into the fold of the reconnaissance mission 
use case. The next step from a systems analysis and design perspective was to create an 
activity diagram, a depiction of the complex flow of activities occurring within each 
phase of BAMCIS (Satzinger, Jackson, Burd, 2012). The activity diagram, or mission 
planning and execution model, is shown in Figure 2. Each row within this model 
represents a phase of BAMCIS and has specific activities and decision points that must 
be completed by a component of the UTACC team. These activities are of significant 
importance to the Coactive Design process. Each one is broken down into its most 
fundamental capabilities. Each capability is then processed and the outputs come in the 
form of the system and user interface requirements. (This process will be broken down in 
further detail during the discussion on Interdependence Analysis Tables.) 
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Figure 2. Mission Planning and Execution Model 



Source; Rice, T., Keim, E. A., Chhabra, T. (2015). Unmanned tactical autonomous 
control and collaboration concept of operations. (Master’s thesis). Naval Postgraduate 
School. Retrieved from Calhoun http://calhoun.nps.edu/handle/10945/47319. 
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As seen in Figure 2, the BAMCIS steps are separated into their own swim lanes 
on the left hand side of the figure. The activities that are identified as unique to each step 
are then listed in a flow chart fashion to the right of the step. This depiction easily guides 
a system’s designer to understand the flow of work from initiation to completion, while 
each activity fits within the Marine Corps user’s troop leading perspective. 

4. Task Analysis Worksheets 

The activities within Figure 2, Mission Planning and Execution Model, are 
collective events that define the interdependent relationships between man and machine. 
Each activity is comprised of many individual subtasks and competencies that require 
further elucidation. Rice et al. (2015) created multiple reference documents to assist with 
these explanations, which are referred to as task analysis worksheets. System modelers, 
while prototyping, can use these documents to understand not only the breakdown of 
work but also the Marine Corps doctrinal reasoning behind why certain activities must be 
performed. These documents have been incorporated into the coactive design model. 

Eigure 3 depicts a generic worksheet and provides descriptions of each field. The 
worksheets are broken down into three separate sections: administrative data, planning 
factors, and UTACC actions. The administrative data was utilized within the coactive 
design process in order to assist with ordering the high-level tasks. Planning factors 
identified additional tasks and capabilities that needed to be incorporated into the 
Coactive Design. Einally, UTACC actions were carried over where appropriate and 
included in the Coactive Design output list of system and interface requirements. 
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Figure 3. Task Analysis Worksheet Strueture 


Administrative Data 

Task Name 

Self-Explanatory 

Task Abbreviation 

Author generated abbreviation for the task 

Catalog Number 

Author generated catalog number for the task 

Parent/Previous Task(s) 

Catalog number of Parent/Previous Task(s) 

Child/Subsequent 

Task(s) 

Catalog number of Child/Subsequent Task(s) 

Parallel Task(s) 

Catalog number of Parallel Task(s) 

Task Summary 

A non-technical description of what must be accomplished to 
complete the task 

Reference Documents 

Self-Explanatory 

Planning Factors 

Threat Analysis 

A synopsis of the role of the threat/adversary that affect task 
performance 

Conditions 

The variables of the environment that affect task performance 

Assumptions 

Events assumed to be true in the absence of facts in order to 
continue planning 

Resources 

The components and subcomponents of UTACC that will be 
utilized to complete this task 

Specified Tasks 

Tasks specifically given by higher headquarters 

Implied Tasks 

Tasks not specifically stated by higher headquarters but are 
necessary to accomplish specified tasks 

Limitations 

Constraints: What must be done 

Restraints: What cannot be done 

Shortfalls 

Resources required to accomplish the task that are not organic to 
UTACC 

UTACC Actions 

Inputs 

Elements required for the task to be accomplished (e.g., tangible 
resources, information requirements, etc.) 

Process 

A non-technical description of the process to assist the modeling 
team 

Outputs 

The results of the process given specific inputs 

Associated lERs 

A list of relevant lERs affected during the process 


Source: Rice, T., Keim, E. A., Chhabra, T. (2015). Unmanned tactical autonomous 
control and collaboration concept of operations. (Master’s thesis). Naval Postgraduate 
School. Retrieved from Calhoun http://calhoun.nps.edu/handle/10945/47319 
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As a future warfighting concept, an important aspect of these worksheets is how 
they tie to Marine Corps reference documents. Rice et al. (2015) took a deliberate 
approach to align these worksheets with current Marine Corps tactics, techniques, 
procedures, and publications. Tying this effort to doctrine increases the likelihood for 
longevity of UTACC within the Marine Corps and makes it easier to build a training plan 
aligned with current programs of record. 

E. UTACC RED CELL 

As a developing technology based warfighting concept, UTACC faces multiple 
security threats during its design and development phases through to its implementation. 
Batson’s and Wimmer’s (2015) thesis, UTACC Red Cell, looked at multiple threats and 
vulnerabilities facing the UTACC system. The objective of the research was to mitigate 
vulnerabilities and facilitate mission success of UTACC missions (Batson & Wimmer, 
2015). Their initial framework for these threats and vulnerabilities was created using the 
National Institute of Standards and Technology (NIST) Risk Management Framework 
(RMF) and DOD’s Information Assurance Certification and Accreditation Process 
(DIACAP). The authors noted the framework led to a threat analysis template that broke 
down UTACC’s inherent vulnerabilities and provided security control strategies to 
mitigate the vulnerabilities. Their findings were separated into non-technical and 
technical categories (2015). The following quote offers a brief description of each of 
these categories: 

Within the non-technical category the following security controls emerged 
as those essential to threat mitigation. 

• Policies, procedures and publications must be analyzed to 
determine specific UTACC system requirements. Requirements 
lead to the development of system specifications which will drive 
operational employment, training, and integration of the system. 

• The UTACC system security policies and procedures must be 
developed to meet the requirements of the DOD and USMC. 

Ensure the UTACC system completes the DIACAP process, which 
ensures the system meets DOD requirements for lA. 
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• Adherence to USMC Communications Security (COMSEC) 
standards and policies which includes physical, cryptographic, 
transmission, and emission security. 

• Training pipeline for leaders, planners, and operators to support the 
UTACC system employment by a USMC unit. 

• Extensive testing and evaluation with operational units. (2015, p. 

41) 

Technical security control reoccurrences do not form as much of a visible pattern 
in the research due to the specificity of the technical security controls to the individual 
threats. The one security control that stands out however is the recommendation for the 
UTACC system to incorporate semi-autonomous modes of operation. This security 
control is mentioned in 27 of the 29 templates. Other technical security controls that 
emerged as those necessary to mitigate threats follow: 

• Remote zeroing of software, data, and cryptographic material. 

• Employ tamper resistant technology. 

• Independent UGV and UAV operations. 

• Redundant and encrypted C2 and data links spread across the EM 
spectrum. 

• Ensure the UTACC network communication links are separated 
from the USMC communication architecture through best practices 
(boundary, firewall, router access control lists. Virtual Eocal Area 
Networks [VEANS]). (2015, p. 42) 

These strategies were considered during the initial coactive design process while 
shaping the system and interface design requirements and should be woven into all future 
UTACC work. Eailure to consider the security and cyber aspects of the system at any 
stage of the development process could introduce weaknesses that a potential adversary 
could then exploit. 

F. SYSTEMS ENGINEERING 

The importance placed on attaining quality system requirements early on with 
feedback from stakeholders is of critical importance to keeping any large scale, complex 
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and multi-disciplinary system within cost and time constraints (Bernard, 2012). This 
process is inherently difficult and while mueh preparation can be achieved up front to set 
initial requirements, continuous communication between stakeholders and developers is 
essential throughout the development. Filtering out the issues from the stakeholder’s 
wants and analyzing them against system boundaries, functions, and scenarios leads to 
the development of realistic requirements. These requirements can then be used in the 
design process to build out the system architecture. 

In the early days of UTACC, MCWL recognized that many of the processes 
which the UTACC system was being designed to perform seemed repeatable. In other 
words, many of the tasks and decisions a robot might make while working toward 
accomplishing a given task were seen again and again, in other similar tasks. Given the 
scale and complexity of what UTACC was attempting to accomplish, it became 
necessary to search for ways of streamlining the colleetion of these requirements. 
UTACC became interested in the coactive design process as a way to efficiently generate 
requirements and allow for this streamlining of information flows to the system 
developers. The benefits of this emergent software design process do not alleviate it from 
the continuous refinement and communication needed between designers and developers 
however. This thesis utilizes the coactive design process to produce an initial list of 
requirements which will need to be adjusted and added to as the system is put through 
scenario testing. 

G. COACTIVE DESIGN 

The recent work done by Johnson (2014) on coactive design offered five major 
contributions to the field of human-robot system design: a fresh design perspective built 
on interdependence, a more comprehensive understanding of interdependence, a model 
for human-machine systems, a design method, and a new tool to assist with system 
design and analysis called the Interdependence Analysis (lA) Table. 

I. Interdependence 

The foundation of coactive design resides on the concept of interdependence. This 

concept is a two way reliance, or symbiotic relationship, between people and machines as 
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they work toward the same goal. It is this view that sets the coactive design method apart 
from other system and software engineering design models. It is viewed by Johnson 
(2014) as the key element of designing collaborative systems. Johnson (2014) stated that 
understanding the nature of the interdependencies between humans and machines 
provides insight into the kinds of coordination that will be required. Johnson et al. (2011) 
asserted that coordination mechanisms in skilled teams arise largely because of such 
interdependencies. Interdependence management is therefore the mechanism by which 
higher level ideas, like collaboration, coordination, and teamwork are achieved (Johnson 
2014). 

Many modern day human-machine systems share responsibility between both 
humans and machines, although the automation is unaware of the humans in the activity. 
Klein et al. (2005) stated that joint activity implies mutual engagements in processes 
extending in time and space. This statement stresses the importance of both humans and 
machines and how they interact together to accomplish the goal. Coactive design aims to 
move away from the common practice of allocating tasks to machines who know little 
about the overall mission goals or about other tasks that the allocated task is reliant on 
(Johnson, 2014). Cummings, da Silva, and Scott (2007) noted that current practices 
ignore the collaboration and collective decision making that is required for successful 
implementation. Miller (2012) stated that a significant fault with supervisory control 
frameworks, where tasks are delegated to machines and supervised by humans, is that the 
rigidly hierarchical task decompositions that they are based upon focus only on the act of 
delegating and not on the context of the delegation. These studies point ardently to the 
fact that humans must be integral components of the systems and not merely users of the 
systems. 

Macbeth, Cummings, Bertuccellie, and Surana (2012) stated that most often 
system users are not considered at the time when algorithm designers create optimization 
algorithms, and that these optimizations are performed even before the interface 
designers develop the interface requirements for how the users will interact. With the 
focus of this thesis to correct that design failure, the users are being considered from the 
beginning and are being looked at for their mutually supporting roles throughout the task. 
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Interdependence also shapes the autonomy of the systems. Johnson (2014) stated 
that the levels of self-sufficiency and self-directedness are very situationally dependent 
and rely heavily on properly understanding the interdependencies between members of 
the team in the unique activity in which they are involved. An agent’s autonomous 
capabilities can thus be shaped during design and implementation to enable correct 
interactions with both people and other agents (Johnson, 2014). 

2. Autonomy 

Prior to the development of the coactive design methodology, Johnson et al. 
(2011) investigated the leading popular design approaches to human-machine teaming. 
Specifically, those approaches were autonomy-centered which presented limited results 
as they did not capture the necessary give and take relationships between all agents. It is 
now well known in the automation industry that automating processes does not 
necessarily simplify complex situations. In fact, it most often has the inverse effect, 
creating even greater need for control and understanding of the situation early in planning 
stages. 

Johnson (2014) reviewed Parasuraman’s, Sheridan’s, and Wickens’ (2000) scale 
on the levels of autonomy, which solely focused on the computer’s process of decision¬ 
making, and viewed it as useless to assisting the designer as it lacked human performance 
measures. Proud, Hart, and Mrozinski (2003) adapted the Parasuraman et al. (2000) scale 
by incorporating the necessary human performance measures within the context of the 
varying levels of autonomy. It parallels the theme of interdependence making it relevant 
to the coactive design approach, and is presented in Figure 4. 
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Figure 4. Levels of Autonomy Assessment Scale 


1 

Obsene 

Orient 

Decide 

.Vet 

Ihc compuUf gathcfs, fillers, .ind 
prionti/cs il«U 

displiN mg an> information to the 
hunun. 

The computer predicts, interprets, 
and integrates data into a result 
Mhich IS rtot displayed to the human. 

The computer performs ranking 
taska The computer performs final 
ranking, but does not display results 
to the human. 

Computer executes 
jutomaiically and does not 
allow any human mteractiort 

7 

Ihc computer gathers, fillers, and 
pfKwiti/cs data HithoU 
dis(^a> mg an> information to the 
human Though, a 'program 
fuiwiRmmg* Hag is dtspla>ed. 

The computer anlay les, predicts, 
interprets, and integrates data mto a 
resuh Mhich is only displayed to the 
human if resuh fits programmed 
conicvt (context dependant 
vummaries). 

The computer performs ranking 
tasks. The computer performs final 
ranking and dtspby s a reduced set of 
ranked optiorts without display ing 
"why * decisions were made to the 
human. 

Computer executes 
automatically and only 
informs the human if required 
by context. It allows for 
override ability after 
execution. Human is shadow 
for contingencies. 

6 

ihc computer gathers, filters, and 
piiOfitues mformalion dtsplased 
to the humaa 

The computer overlays predictions 
with aralysis and interprets the data. 
The human is shown all results. 

The computer performs ranking tadis 
and displays a reduced set of raivked 
options while displayir^ "why* 
decisions were made to the humaa 

Computer executes 
auuvmatically, informs the 
human, and allows for 
merrtde ability after 
execuiRin. Human is shadow 
contingencies. 

5 

I he computer is respoitsdile for 
gathering the information for the 
human, but it only display s non* 
priofiti/cd, filtered information. 

The computer overlays predictions 
with analysis and interprets the data. 
The human shadows the 
interpretation for contingencies. 

The computer performs ranking 
tasks. All results, mcluding "why * 
decisions were made, are displayed to 
the humaa 

C'omputer allows the human a 
context-dependant restricted 
time to veto before executioa 
Human shadows for 

cvmtmgenctex 

4 

The computer is responsible for 
gathering the information for the 
human and for displaying all 
mformation, but it highlights the 
norvprioritized, relesant 
information for the user. 

The computer analy zes the data and 
makes predictions, though the 
human is responsiMe for 
interpretation of the data. 

Both human and computer perform 
ranking tasks, the resuhs from the 
computer are considered prime. 

Computer allows the human a 
pre-programmed restricted 
time to veto before executioa 

Human shadows for 
cvmtingenciev 

3 

I he computer is responsible for 
gathering and displaying 
unfiltercd. unprioriti/ed 
information for the human. The 
human still is the prime monitor 
for all informatioa 

Computer is the prune source of 
aruly sa and predictions, w ith 
human shadow for contingencies. 
The human is responsible for 
interpretation of the data 

Both human and computer perform 
ranking tasks, the resuhs from the 
human are considered prime. 

Computer executes decision 
after human approval. Human 
shadivws for contmgencies. 

2 

Human is the prime source for 
gathering and morulormg all data, 
sstth computer shadows for 
cmefge OCR'S. 

Human is the prime source of 
aruly scs and predictions, w ith 
computer shadow for contingencies. 
The human is responsible for 
interpretation of the data 

The human performs all ranking 
tasks, but the computer can be used 
as a tool for assistance. 

Human is the prime source of 
exccutum, with computer 
shadow for contingencies. 


Human is the onK source for 
gathering and monitoring 

1 defined as filtering, prioritiaif^ 
and understandmglall data. 

Human is responsible for analy zing 
all data making predictions, and 
interpretation of the data 

The computer does not assist in or 
perform ranking tasks. Human must 
do It all. 

Human alone can execute 

dccisioa 


Source: Proud, R., Hart, J., & Mrozinski, R. (2003). Methods for determining the level of 
autonomy to design into a human spaceflight vehicle: A function specific approach, Proc. 
Performance Metrics for Intelligent Systems, NIST Special Publication 1014, September 
2003. 


Figure 4 possesses a level of autonomy axis and an observe, orient, decide, and 
act (OODA) loop axis. OODA was developed by the military as an attempt to disrupt the 
enemy’s processes of decision making. It is a familiar concept to all Marines, taught early 
in entry level training and referred to regularly thereafter. Proud, et al. (2003) tailored 
each level of autonomy to fit the tasks within each function of OODA. The Observe 
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column encompasses gathering, monitoring, and filtering data; the orientation column 
encompasses analysis, prediction, and interpretation; the decision column refers to 
ranking options and choosing one; the action column refers to execution of the option 
chosen (Proud et al., 2003). The levels of autonomy, range from the lowest level, level 1, 
where the human is fully responsible for all actions performed with respect to OODA, to 
the highest level, level 8, where the system is fully responsible for all actions (Proud et 
ah, 2003). 

While the coactive design method as developed by Johnson (2014) was developed 
in the absence of Figure 4, this author used it to conceptualize how to expand the single 
human-single machine dynamic explored in Johnson’s (2014) studies to the more 
complex dynamic presented within the multiple human-multiple machine, UTACC 
system. The UTACC system developers can use the construct of Figure 4 as UTACC 
missions mature beyond what is currently being explored at the time of this writing. It is 
necessary to stress that the UTACC system is not envisioned to fall within one particular 
level of this scale but that it should be capable of being placed initially into a level and 
then dynamically adjusting it throughout any particular mission based on an evolving 
situation. Being able to meet this demand further stresses the crucial need for 
understanding the complex interdependencies of the team. 

3. Coactive System Model 

Having stressed the importance of interdependence and what it means to be 
interdependent, this thesis moves next to the model for human-machine systems. This 
model emphasizes how managing and supporting interdependent relationships is possible. 
This model serves as a means for guiding the designer to relevant issues needing to be 
addressed, defines appropriate specifications, and also aids in evaluating alternatives. 

Johnson et al. (2014) viewed Fong’s (2001) collaborative control method as the 
most descriptive model existing in literature at the time of their research. Fong’s (2001) 
innovation was in stating that the human should be permitted to make perceptual or 
cognitive decisions for the robot through a user interface (UI) that the robot provides 
inputs to. Fong’s (2001) model considered the internal processes of the robot and how 
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they manifested to the user as opposed to depicting the robot as a black box of 
uncertainty. In modeling how perception and cognition occurred in the robot there were 
ways to vary how the human could interact with them (Fong, 2001). Fong’s (2001) model 
was suited to individual activity—as opposed to joint activity—and how the simple tasks 
were handed off from human to robot. This method more closely resembled teleoperation 
of a robot by a human as opposed to what Johnson et al. (2014) sought to model, which 
was an interdependent relationship through the conduct of a joint activity. The Johnson et 
al. (2014) model highlights the importance of internal processes similar to Fong’s (2001) 
work but with the additional requirements necessary to conduct joint activity: 
observability, predictability, and directability (OPD); it is presented in Figure 5. 

Figure 5. Coactive System Model 



Source; Johnson, M. (2014). Coactive design: Designing support for interdependence in 
human-robot teamwork. Doctoral dissertation. Delft University of Technology- 
Mekelweg/Netherlands. 


4. Observability, Predictability, and Directability 

The following quote from Johnson’s (2014) work clarifies what it means to be 
observable, predicable, and directable: 
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Observability means making pertinent aspects of one’s status and 
knowledge of the team, task and environment observable to others. 
Observability also involves the ability to observe and interpret pertinent 
signals. It plays a role in many teamwork patterns e.g., monitoring 
progress and providing backup behavior. 

Predictability means one’s actions should be predictable enough that 
others can reasonably rely on them when considering their own actions. 
Predictability also involves considering other’s actions when developing 
one’s own. It is essential to many teamwork patterns such as 
synchronizing actions and achieving efficiency in team performance. 

Directability means one’s ability to direct the behavior of others and 
complementarily by directed by others. It includes explicit commands 
such as task allocation and role assignment as well as subtler influences, 
such as providing guidance or suggestions or even providing salient 
information that is anticipated to alter behavior, such as a warning. 
Teamwork patterns that involve directability include such things as 
requesting assistance and querying for input during decision making. 

By using the OPD framework as a guide, a designer can identify the 
requirements for teamwork based on which interdependence relationships 
the designer chooses to support. The framework can help a designer 
answer questions such as ‘What information needs to be shared,’ ‘Who 
needs to share with whom,’ and ‘When is it relevant.’ The goal of the 
designer is to attain sufficient OPD to support the necessary 
interdependent relationships. (2014, pp. 68-70) 

This OPD framework shifts the focus from one individual component, either the 
robot or the human, to the team components and how they both affect one another 
(Johnson, 2014). The framework separates individual task accomplishment from 
teamwork. The interface represents the mechanism required to support this 
interdependence (Johnson, 2014). 

5. Coactive Design Method 

Conveying abstract concepts like coordination, cooperation, and collaboration 
into system designer friendly forms, or system requirements implemented through control 
algorithms, interface features, and behaviors, is challenging. The coactive design method 
translates these complex concepts into useful system requirements by managing 
interdependent activities (Johnson, 2014). With an understanding of what it means to be 
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interdependent, the OPD requirements, and the Coaetive Design Model it is now 
appropriate to eonsider in detail the Coactive Design Method, illustrated in Figure 6. 


Figure 6. Coactive Design Method 



Source: Johnson, M. (2014j. Coactive design: Designing support for interdependence in 
human-robot teamwork. Doctoral dissertation. Delft University of Technology- 
Mekelweg/Netherlands. 
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As seen in Figure 6, the Coactive Design Method has three main processes: 
identification, selection and implementation, and evaluation of change. Each process is 
then further broken down into inputs, sub-processes and lastly outputs. The design of 
Figure 6 can be misleading as the steps seem to flow in a stepwise fashion from block to 
block resembling a waterfall design process. When modeling processes with a waterfall 
design, the requirements are mostly understood upfront and allow developers to move on 
to subsequent phases without needing to revisit previously completed phases (Satzinger 
et ah, 2012). However, the feedback loops to the side of the figure are of critical 
importance in understanding the process and must be fully conveyed to all stakeholders 
invested in the system’s development. These loops illustrate that the Coactive Design 
Method contains many adaptive elements that evolve through iteration, which is what 
Satzinger et al. (2012) considers spiral modeling. This adaptive, spiral modeling process 
not only suggests that the identification, selection and implementation, and evaluation 
processes of the Coactive Design Method be repeated but necessitates repetition in order 
to produce solutions that more accurately capture the interdependent activity. 

a. Identification Process 

Johnson (2014) differentiated the Coactive Design Method from traditional task 
analysis techniques through its unique analysis of interdependence by: 

• Allowing for soft constraints 

• Allowing for more types of interdependence than just task dependency 

• Representing other participants in the activity by name or by role 

• Allowing for assessment of capacity to perform 

• Allowing for assessment of capacity to support 

• Allowing for consideration of role permutations 

The identification process within Coactive Design is made possible through an 
analysis tool that Johnson et al. (2014) refers to as the Interdependence Analysis (lA) 
Table, Figure 7. This author adapted the Johnson et al. (2014) Interdependence Analysis 
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Table to meet the larger, many human-many machine, UTACC teaming environment. 
The adapted UTACC lA Table is presented in the following chapters of this thesis. 


Figure 7. Interdependence Analysis Table 
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Source: Johnson, M. (2014j. Coactive design: Designing support for interdependence in 
human-robot teamwork. Doctoral dissertation, Delft University of Technology- 
Mekelweg/Netherlands. 


Figure 6, the Coactive Design Method, provides guidance on how to navigate and 
manipulate the lA Table depicted in Figure 7. The identification process begins with 
traditional task analysis. The left most columns of the lA Table break down tasks into 
manageable granularity. Capacities are defined as the knowledge, skills, and abilities that 
are necessary for the tasks. These include perceptual, decision making, and specific 
action needs (Johnson, 2014). The next sections, moving right across the table, enumerate 
the team role alternatives by identifying the primary actor that will be accomplishing the 
task and the remaining team mates in supporting roles. Alternatively, a different actor 
may serve as the primary with a different cast of agents in supporting roles. In listing 
these alternatives it becomes possible to identify the best suited team member for 
fulfilling a task and communicates that a level of support is required by the rest of the 
team. After alternatives were determined, Johnson (2014) then assessed the individual’s 
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ability to provide the required capacity or ability to support the performer. This 
assessment is made possible through the use of the following color coding scheme 
(Figure 8). 


Figure 8. Interdependence Analysis Coloring Scheme 


Team Membef Role Alternatives 

Performef 

Suppoding Teom Members 

1 can do it all 

My assistance could improve efficiency 

1 can do it all but my reliability is < 100% 

My assistance could improve reliability 

I can contribute but need assistance 

My assistance is required 

I cannot do it 

I cannot provide assistance 


Source: Johnson, M. (2014j. Coactive design: Designing support for interdependence in 
human-robot teamwork. Doctoral dissertation. Delft University of Technology- 
Mekelweg/Netherlands. 


It is important to note the colors take on different meanings with respect to 
describing the performer verses the supporting team members. The performer column 
breaks down the individual’s capacity to perform a task. Colors in the supporting member 
column indicate potential to support the performer—and not the ability of that team 
member to do the task themselves. A simple example of how the differences play out 
may illustrate the point further. In the case of a robot as the performer and a human as a 
supporter, the robot may be able to search a room while looking for an object all on its 
own. However, introduce a tall table into the room and place the object on it, out of view 
of the robot, and the robot is unable to complete the task with 100 percent reliability. 
Having a human check the table would improve that reliability. Shading in the lA Table 
would then color the performer column with yellow and the supporting column with 
yellow. 

Coloring patterns can be analyzed once all performer and supporting alternatives 
are complete providing the designer insight into the interdependence of the relationships 
(Johnson, 2014). Figure 9 summarizes the different color combinations and what the 
corresponding color combinations represent. 
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Figure 9. Potential Interdependence Analysis Table Color Combinations 
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Source: Johnson, M. (2014j. Coactive design: Designing support for interdependence in 
human-robot teamwork. Doctoral dissertation. Delft University of Technology- 
Mekelweg/Netherlands. 


The following quote from Johnson (2014) illustrates the importance in 
understanding the color combinations: 

Overall, the colors in the first column provide an understanding of how the 
performer would fare if required to meet the capacity requirement 
autonomously. Colors other than green in the performer column indicate 
some limitation of performer, such as potential brittleness due to reliability 
(yellow), hard interdependency due to lack of capacity (orange), or just a 
complete lack of capacity (red). 

The supporting team member columns provide an understanding of what 
type of interdependence relationships could potentially be supported. The 
color red in these columns indicates that there is no chance for assistance. 

This makes the performer a single point of failure. If the performer is less 
than 100 percent reliable, you will have a brittle system. However, if you 
can provide support for interdependence then you can avoid the single 
point of failure. Colors other than red in the supporting team member 
column indicate potential required (orange) or opportunistic (yellow and 
green) interdependence relationships between team members. The hard 
interdependencies are usually easy to identify because you cannot 
complete the task without it. Soft interdependencies tend to be more 
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subtle, but provide valuable opportunities for teamwork and alternative 
pathways to a solution. (2014, pg.77) 

It is thanks to this relatively simple set of color combinations that repeatable 
patters in behaviors and support relationships are made easily identifiable. As a result, 
Johnson (2014) stated that it becomes increasingly simple to identify the following: 

• Agents lacking capacity and those that can offer it 

• Agents lacking 100 percent reliability and those that can supplement it 

• Capacity overlaps that provide opportunistic relationships 

Johnson (2014) stated that the OPD requirements derive from these interpretations 
and answer the questions: 

• Who needs to observe what, from whom? 

• Who needs to be able to predict what? 

• How do members need to be able to direct each other? 

After these requirements have been identified, a system’s designer will possess a 
set of interdependent relationships that must be supported by the system and the 
requirements that make those relationships possible. This completes the identification 
process, the first of three processes, within Figure 6, the Coactive Design Method. The 
remaining two processes, the selection and implementation process and the evaluation of 
change process, keep to their respective name sakes and require little explanation. The 
selection and implementation process involves finding design mechanisms capable of 
meeting the requirements obtained in the identification process and implementing them. 
The evaluation of change process consists of ensuring the mechanisms chosen to support 
the requirements adequately meet expectations and that no secondary effects on other 
OPD relationships have resulted from their implementation. These feedback loops, as 
indicated in Figure 6, lend themselves to an iterative, spiral design process as described 
by Satzinger, et al. (2012). If other OPD relationships are affected or if additional tasks or 
capabilities are identified they need to be inserted into the identification process and the 
Coactive Design Method rerun. Once all possible solutions have undergone and passed 
their performance and human integration tests the system will be ready for deployment. 
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H. CHAPTER CONCLUSION AND SUMMARY 


This chapter began with the UTACC vision and overview and stated the need for 
continuing the exploratory initiative, expressed in EF21. There were two major bodies of 
work analyzed and merged together under this thesis’ research. The first body of work 
was Rice’s et al. (2015) UTACC Concept of Operations which possesses the Mission 
Execution and Planning Model and the Task Analysis Worksheets. The second effort 
analyzed during this research was Johnson’s (2014) Coactive Design Method, including 
an iterative Coactive Design Model and the Interdependence Analysis Tables. 
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III. RESEARCH METHODOLOGY 


In 2013, the Marine Corps Warfighting Laboratory (MCWL) began exploring the 
Unmanned Tactical Autonomous Control and Collaboration (UTACC) initiative. Rice et 
al. (2015) and Batson and Wimmer (2015) pioneered the early development of the 
UTACC concept and validated the concept’s viability by providing initial concept 
designs and threat and vulnerability assessments. In the short term, these results meant 
the continuation of the program and the exploration of capturing what were traditionally 
human to human interactions and the translation of these interactions when a machine is 
substituted into the equation. The successful achievement of this end state sets the 
conditions for the final, long term configuration of UTACC, laid out as a “decision¬ 
centric, semi-autonomous, distributive, multi-agent, multi-domain robotic system” 
(SOW, 2014). 

With this configuration in mind for the foundation of UTACC, the next step 
forward was to determine the special information exchange requirements between 
Marines and machines that ought to be implemented into the UTACC system. Coactive 
design was chosen as the method for documenting these exchanges, since research 
indicated that it was the only systems engineering process available that enabled 
requirements generation for robot-Marine teaming. This thesis looked at the feasibility of 
incorporating coactive design as a repeatable process within the UTACC Enterprise 
Engine. To accomplish the incorporation of Coactive Design, the lead architect of the 
original Coactive Design Method, Dr. Matthew Johnson, was sought out to teach this 
author how to apply the method to the UTACC initiative. The author conducted two 
separate trips to the Institute of Human Machine Cognition (IHMC) where Johnson 
continues his work with Coactive Design. The first trip sought to educate the author on 
the process and the second trip validated the application of this knowledge to UTACC. 

A. DEFINITION OF THE PROBLEM 

The Rice et al. (2015) Mission Planning and Execution Model and Task Analysis 
Worksheets were well suited to the initial proof of concept. However, there are a number 
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of reasons why the Rice et al. (2015) model, as a standalone, should not be used by 
UTACC system designers for future consideration. The work of Rice et al. (2015) was 
limited in scope as it only analyzed the reconnaissance mission and not indicative of 
reconnaissance missions in general. The UTACC system is envisioned to be adaptive to a 
wide range of dynamically changing missions. 

The Mission Planning and Execution Model also failed to record the level of 
interaction between agents necessary to complete tasks within a larger mission set. 
Without this information the reliance on specific environmental conditions being met 
before work can be accomplished is high. It is the identification of perceptual, cognitive, 
and physical needs that provides insight into what interdependencies are at play and 
which agents are best suited to perform and support tasks. The interdependent framework 
of the Coactive Design Model and the Interdependence Analysis Tables provide the level 
of responsiveness that a system like UTACC needs to be built around. An agile and 
system conscious design method like coactive design is more efficient in both the short 
and long term; Coactive Design’s main selling point is that it delivers design mechanisms 
to developers that more accurately capture the system as a whole. 

At the time of this writing a second round of UTACC demonstrations has been 
planned. The goal of the demonstrations is to exhibit a few new features of the systems 
but the context of a controlled reconnaissance mission remains the same. The existing 
work of Rice et al. (2015), specifically the Mission Planning and Execution Model, 
became a natural starting place for this research. The author attempted to incorporate as 
much of that work into the Coactive Design Model as possible. The successful merger of 
these two models would aid in the increased dissemination and acceptance of the new 
model with respect to those involved with the UTACC initiative and the prospective user 
community. This preservation of the existing UTACC knowledge base would send a 
message more in line with a software upgrade rather than an operating system switch, and 
this would result in being viewed as only minimally invasive to MCWL. 
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B. MODIFYING COACTIVE DESIGN PROCESSES FOR UTACC 


During the first trip to IHMC, the author gained insight into how the Coactive 
Design Method operated within the context of IHMC’s unique operating environment. 
That body of knowledge is summarized in the Chapter Two literature review. While 
many similarities exist between IHMC’s work and that which UTACC aims to achieve, 
the UTACC operating environment presents many unique challenges that were not 
relevant to IHMC. 

I. UTACC Interdependence Analysis Table 

As an illustration of this point, the IHMC construct revolved around a single 
humanoid robot, whereas the UTACC initiative seeks a multi-domain, multi-agent 
system. Despite these differences, the Coactive Design Method as proposed by Johnson 
(2014), and illustrated in Figure 6, remained unaltered. However, the analysis tool 
utilized to accomplish this method had to be tailored accordingly. The modified UTACC 
Interdependence Analysis (lA) Table with cell descriptions is listed in Figure 10. 


Figure 10. UTACC Interdependence Analysis Table 
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Adapted From: Johnson, M. (2014). Coactive design: Designing support for 
interdependence in human-robot teamwork. Doctoral dissertation, Delft University of 
Technology- Mekelweg/Netherlands. 
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The UTACC Interdependence Analysis Table also reflects the desire to maintain 
as much of the pre-existing concept design from the Rice et al. (2015) thesis work as 
possible. Incorporating the essentials of the Mission Planning and Execution Model 
developed by Rice et al. (2015), required several modifications to the original lA Table as 
developed by Johnson (2014). An additional column was added to the front of the table 
which groups tasks within the Marine Corps Troop Leading Steps. Alternative teaming 
roles were expanded to allow for multi-domain, multi-robotic agents, including the 
potential for the human to serve as the performer with the robotic elements serving in the 
support roles. The most developed UTACC use case allows for multiple air and multiple 
ground robots, as well as, multiple humans. However, this work distilled the UTACC use 
case down into a single unmanned ground system (UGS), unmanned air system (UAS), 
and human element. The three different teaming role alternatives are then a rotation of 
performer among the three agents while the remaining agents serve in support roles. 

2. UTACC Color Scheme 

When the lA table was modified to meet the needs of the UTACC initiative, the 
author noticed an expanding level of complexity, corresponding to the need to analyze 
three teaming role alternatives as opposed to two in the Johnson (2014) work. By 
eliminating many of the possibilities that were inherently not feasible, the author could 
more easily sift through numerous possibilities of interdependent relationships and 
interpret more accurately what the color combinations represented. Figure 11 depicts the 
modified UTACC lA Color Scheme. 
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Figure 11. UTACC Interdependence Analysis Color Scheme 



Performer 

Supporting Team Member 

I can do it all 

My assistance could improve 
efficiency 

I can do it all but my reliability is < 
100% 

My assistance could improve 
reliability 

I can contribute but need assistance 

My assistance is required 



Not applicable 

Not applicable 


Adapted from: Johnson, M. (2014). Coactive design: Designing support for 
interdependence in human-robot teamwork. Doctoral dissertation, Delft University of 
Technology- Mekelweg/Netherlands. 


The color gray added to the Interdependence Analysis Color Scheme makes it 
easier to analyze interdependent teaming role alternatives. Simply, the color gray 
represents the agent is not in the role of the performer or the supporting team member and 
is not applicable for consideration. An example of when this color simplifies analysis of 
teaming role alternatives follows. Figure 12 helps illustrate the example. 


Figure 12. Example UTACC lA Color Scheme 



The example explains how the author applied the color scheme to the capacity of 
resolving airspace. In this case, the UAS must be the performer. So the alternatives where 
the human and UGS are the performer, the alternates would be completely gray and thus 
eliminate the need to analyze them later in the Coactive Design Method. Also, as the 
UGS is restricted to the ground, it would be unable to help the UAS resolve airspace and 
therefore would be shaded gray under the supporting team member column. This would 
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leave only the human in the role of supporting the UAS as lacking a color. In this 
manner, eliminating seven out of nine relationships with regard to one capacity greatly 
reduces the complexity of the resulting color schemes and allows the coactive designer to 
focus their attention on this one interdependent relationship. 

C. CHAPTER SUMMARY 

This chapter began by outlining the issues with the old Mission Planning and 
Execution Model, as developed by Rice et al. (2015). Coactive Design was selected to 
resolve these issues and serve as the system’s development method for the duration of the 
UTACC program. Coactive Design required slight process modifications in order to 
seamlessly fuse UTACC concepts. Among the most significant modifications were the 
minor alterations made to the lA Tables framework and the additional category added to 
the lA Color Scheme. An example was provided to illustrate how these modifications 
accommodated the UTACC construct by simplifying analysis, despite UTACC 
possessing a larger framework than Coactive Design was originally designed to handle. 
The next chapter will explore the results of applying the Coactive Design method to 
UTACC. 
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IV. UTACC COACTIVE DESIGN RESULTS 


This section delivers an executive overview of the results from applying Coactive 
Design to Unmanned Tactical Autonomous Control and Collaboration (UTACC). This 
executive summary will focus on major components of the Interdependence Analysis 
(lA) Tables, many of which were supported by the Task Analysis Worksheets of Rice’s 
et al. (2015) work. 

The work flow analyzed by the UTACC Coactive Design was modeled off of the 
Marine Corps Troop Leading Steps, a work break down structure organic to the Marine 
Corps that forms the basis of mission planning. The steps of this structure spell out the 
acronym BAMCIS and consist of: Begin the Planning, Arrange for Reconnaissance, 
Make Reconnaissance, Complete the Plan, Issue the Order, and Supervise Activities. An 
lA Table was developed for each of these steps. 

Due to the size of the lA Tables, they had to be partitioned off to allow for 
discussion in this format. Depending on the number of tasks within each BAMCIS step, a 
particular lA Table may be split into many sections. These partitions also serve the 
purpose of incrementally stepping through the way the lA Tables were created. This 
presentation style will assist any follow on Coactive Designer in understanding the 
author’s train of thought, which was heavily influenced by his infantry experience. All of 
the resultant lA Tables’ tasks are stacked, decomposed and analyzed within the 
alternative teaming options and possess observability, predictability, and directability 
(OPD) requirements. This chapter will present the lA Tables with a discussion of the 
OPD requirements and key takeaways for developers. 

A. BEGIN PLANNING lA TABLES 

The first phase of the Troop Leading Steps work flow is the B in BAMIS: begin 
planning. The tasks associated with UTACC in this phase involve initiating the system 
and setting preferences and then entering mission parameters based on a directive 
received from a higher level command, thus initiating a mission. 
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1. Begin Planning: Initiate System and Set Preferences 

Initiating the system and setting preferences involves the subtask of setting the 
desired level of autonomy. This subtask is broken down into defining the general nature 
of each human-machine relationship and having the system understand its role within 
each different level. Figure 13 depicts this task decomposition and provides the OPD 
requirements for achieving it. 


Figure 13. Begin Planning lA Table: Initiate System and Set Preferences 
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The OPD requirements drawn from this lA Table are concerned with calibrating 
the system, identifying all participating teammates, and establishing the desired level of 
autonomy that is initially required of the system. Coordinating instructions for events that 
concern contingencies (e.g., loss of communication with the robots, and necessity to 
adjust the level of autonomy mid-mission) are listed as well. The process of facilitating 
the interface design is also mentioned in the table. 

2. Begin Planning: Enter Mission Parameters 

The mission parameters have been delineated in a format that all Marines are 
fa mi liar with, known as the Five Paragraph Order (5PO). OSMEAC is the acronym used 
to teach the 5PO and stands for Orientation, Situation, Mission, Execution, 
Administration and Eogistics, and Command and Signal. Each has been assigned as a 
subtask and is further broken down within the capacity field of the lA Tables. 

The Marine unit leader must receive the tasking directive and relay it to his unit 
before setting them in motion. As UTACC is now a member of the unit, that unit leader 
must now relay the directive to it as well. It is perceived that entering these parameters 
will benefit the unit leader’s understanding of the mission and better facilitate the 
translation of the mission to the human teammates, as well. 

a. Five Paragraph Order: Orientation and Situation 

While the orientation is not one of the essential five paragraphs within the 5PO, it 
is necessary for properly framing the mission. With regard to UTACC, that translates into 
ensuring the system understands the operating area. An effective orientation sets the stage 
for the situation which has an enemy and a friendly component. Eigure 14 depicts the O 
and S portions of this task decomposition and provides the OPD requirements for 
achieving it. 
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Figure 14. Begin Planning lA Table: the OSMEAC “O” and “S” 
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The OPD requirements associated with achieving the O and S are concerned with 
input fields on the user interface. The Marine must provide this information in order to 
convey where the system will be operating, if friendly forces or the effects of friendly 
forces will be experienced, and whether or not to anticipate resistance from perceived 
threats. 


b. Five Paragraph Order: Mission 

The mission paragraph is where the overall mission of the team is described— not 
to be confused with the individual assignments of the team members, which are referred 
to as tasking statements and follow later in the 5PO. Also of note, a tactical task is the 
term for the action to be conducted during a mission. All mission statements and tasking 
statements must contain one, and only one, tactical task. A list of published tactical tasks 
with clear definitions that permit Marines the ability to quickly communicate desired 
actions and outcomes can be found in Marine Corps doctrinal publications like MCRP 5- 
12a: Operational Terms and Graphics. New tactical tasks may need to be developed as 
systems find their way onto the battlefield. Such discussion is beyond the scope of this 
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thesis. Understanding the mission of the system within the related mission of the team is 
the capaeity deseribed in Figure 15. 


Figure 15. Begin Planning lA Table: the OSMEAC “M” 
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The OPD requirements listed in Figure 15 describe a list of input fields needed on 

the user interface that will shape how and what tasks the systems will perform. The 

additional details will help ensure that the system’s actions (which will be specified in the 

tasking statements) are nested within the team’s mission. 
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c. Five Paragraph Order: Execution 

The next paragraph of the 5P0 is Execution and revolves around the physical 
actions, setting conditions, and sequencing of events. In order to convey this information, 
the paragraph is broken down into several subparagraphs: the Commander’s Intent within 
the Concept of Operations (CONOPS), the Scheme of Maneuver (SOM) within the 
CONOPS, the Fire Support Plan (ESP) within CONOPS, Tasking Statements, and 
Coordinating Instructions. Figure 16 depicts this breakdown and the OPD requirements 
necessary to achieve them. Further, this establishes the shared objective between Marines 
and machines. 
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Figure 16. Begin Planning lA Table: the OSMEAC “E” 
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Many of the perceived benefits of including all of the elements of the 5PO into 
this lA Table relate back to the influence they have over the thought processes of the unit 
leader. While a particular element may or may not directly impact the actions of a team 
member (whether Marine or machine), they remain a part of the planning process for the 
role they play in the larger picture. Within the execution paragraph it becomes easy to 
develop tunnel vision and hone in on tasks; that is, after all, what the unit leader will be 
ordering the systems and Marines to go out and accomplish. It is the other elements of 
this paragraph that tie the otherwise disjointed tasks together. The OPD requirements 
described in Figure 16 help guide the design of the interface to quickly guide the user 
through developing their plan. 

d. Five Paragraph Order: Admin / Logistics and Command / Signal 

The final two paragraphs of the 5PO are the administration and logistics plan and 
the command and signal plan. True to their names, these paragraphs deal with personnel 
and robot accountability, resupply and refueling, communication architectures, and 
succession of authority or command relationships. The capacities listed in Figure 17 
detail these points and provide the OPD requirements necessary to achieve them. 
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Figure 17. Begin Planning lA Table: the OSMEAC “A” and “C” 
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The OPD requirements listed in Figure 17 focus more on system requirements 
than on interface design. The fields of information are of use to the system in identifying 
and tracking friendly units; understanding where to go and what to do when 
electronically cut off from the team; prioritize who to take commands from; and when 
and how long to communicate. These two final paragraphs, the “A” and “C” paragraphs 
of the 5PO, complete the Begin Planning phase of the BAMCIS work flow. 

B. ARRANGE RECONNAISSANCE lA TABLES 

The second phase of the Troop Leading Steps work flow is the A in BAMCIS, 
arrange reconnaissance. The tasks associated with UTACC in this phase involve 
conducting initial mapping in order to orient the team to the area of operations and 
selecting emphasis areas. 

1. Arrange Reconnaissance: Conduct Initial Mapping to Orient 

Conducting initial mapping to orient involves the following subtasks: depart 
friendly lines; scan area between origin and objective for geographic features; scan 
objective area for basic geography; build a map; notify when near the completion of 
mapping; monitor system health; review initial map highlight areas for further 
refinement; and query external joint assets. Due to the size of the Arrange for 
Reconnaissance lA Table, it was broken down into four smaller lA tables for the ease of 
presenting it in this thesis. 

a. Initial Mapping: Depart and Scan between Origin and Objective 

Figure 18 depicts the task decomposition for the first two of six subtasks under 
the task for conduct initial mapping to orient; it also provides the OPD requirements for 
achieving them. 
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Figure 18. Arrange Reeonnaissanee: Initial Mapping: Depart and Sean 

between Origin and Objeetive 

_ I Opfcin 1 I Opio»i 2 I Oetofi 3 


Cttaatf 


Conduct 
Initial 
Mapping 
to Onent 


Depart 

Friendly 

Lines 


Scan 

Area 

Between 

Ongin 

and 

Otijectiv 
e for 
Geo 

Features 


Resolve 

Airspace 



Understan 
Szeof 
Area to 
Scan 
Between 
Ongin and 
OPiective 


Ran for 
How to 
Scan the 
Area 



Humans can (^conflict ar space and it would also be hdpful 
tobuHd in this capability into the UAS. {need them to not 
bump into each other and be able to take off and get into 
scan pattern amazon suggests Establishing fty zones from 
UAVs have ceilings (AOOftwith lOOft buffer above) and No 
Fly Areas for restricted ar space These normal altitude 
parameters should be default set and used m the design of 
lenses and imagine devices but should allow for field 
mocWcations, especially the NFAs Examples of NFAs 
include active landing zones and drop zones, holding areas 
for helicopters, and other ar control measures where arcraft 
are designated to operate in The ability for miitary ar craft to 
share the same arspace would require ability for drone to 
detect manned (and unmanned arcraft) and deconflict in an 
EM contested environment Also, should be able to tap into 
gun target lines and surface danger zones todeconflict| 
altitude with artillery and mortar traiectones This can be 
accomplished by drone ability to remotely access command 
battle tracking systems.(initial map is a geographic map that 
IS captured by the UAS only .) 


the human must determine and communicate the size 
(overlap of scans)and locabon of the area to be scanned the 
human can streamline efficiency and timeliness of the system 
by constraning the initial mapping of the area This requires 
an interface that allows the human to input military gnds 
(MGRS) A scaled gnd square of varying dimensions can 
then by applied to a military map projection display for the 
human to ’shave off unnecessary scan areas ' it wi also be 
necessary for the human to identify starting point through use 
of gnds and or other points of interest through gnds or 
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The OPD requirements for the resolving airspace capacity involve free and safe 
flight of the UAS from takeoff to landing. The OPD requirements associated with 
understanding the size of the area to scan between origin and objective established a box 
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shaped operating area for the UAS with the origin in one corner and the objective in the 
comer diagonally opposite. The OPD requirements for the task, plan how to scan the 
area, identify information that the system must provide to the Marines. 

Figure 18 offers the first glimpse of true interdependence at work during the 
BAMCIS process. The pattern of colors that emerges from Figure 18 indicates that the 
Marine and machine are communicating with one another and are relying on one another 
to do some element of work that the other is incapable of conducting. The first row 
within Figure 18 shows that the UAS is capable of carrying out the given capacity. The 
second row depicts a hard constraint, i.e., a hard interdependence, where the human is 
required to perform a function. The third row shows that the UAS is capable of carrying 
on with planning after receiving human input. The OPD requirements for this row 
provide the Marine a visual aid to understand what the UAS scan path and time of flight 
will look like, based off how that Marine shapes the scan area (the information exchange 
from the second row of Figure 18). 

Figure 18 offers insight regarding where UTACC should spend time and 
resources during the development cycle and where it should not. The hard 
interdependencies of row two in Figure 18 should be avoided from an automation 
perspective. The Marines have the ability to quickly and effortlessly provide a capability 
that the system is incapable of mastering, rather than getting bogged down trying to 
marginally provide an automated capability that the Marine is available for and would 
prefer to have control of in the first place. Development should, however, focus on rows 
one and three of Figure 18. The issues with rows one and three can be fixed during 
development. These issues lie in the translation of the [already present] information that 
is necessary for Marines and machines to make their decisions. The human must 
determine and prioritize what is important to scan. That ability is greatly enhanced if the 
system can visually display a correlated time of flight and scan path as the Marine plays 
with the parameters of the scan box. These requirements introduce opportunities for the 
Marines and robots to share information for the first time during the BAMCIS process. 
This theme will emerge several times over throughout the remainder of the lA Tables’ 
analysis. 
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b. Initial Mapping: Scan Objective and Build Map 

The second set of subtasks under the task of conduct initial mapping to orient are: 
scan objective area for basic geography and build the map. Each subtask has multiple 
capacities: execute initial mapping protocol; generating actionable information; 
transmitting map information; identifying between urban and wooded areas; and 
identifying masked areas. The OPD requirements for these capacities are shown in Figure 
19. 


Figure 19. Arrange Reconnaissance: Initial Mapping: Scan Objective and 
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The OPD requirements for Figure 19 are centered on improving the UAS in the 
performance of its duties and not in translating information from Marine to machine or 
vice versa. These requirements aim to improve sensor quality and processing on board 
the system and are only limited to the scope of current technology. This is much simpler 
to address compared with translating information exchanges between Marines and 
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machines. Similar to the Begin Planning lA Tables, where the human was doing the 
majority of the work, here the UAS is required to take on the lion’s share of the work. 

c. Initial Mapping: Notify when Complete and Monitor System Health 

The final two subtasks of the task conduct initial mapping to orient are: notify 
when near eompletion of mapping and monitor system health. Each has one capacity and 
the OPD requirements associated with achieving them are listed in Figure 20. 


Figure 20. Arrange Reconnaissance: Initial Mapping: Notify when Complete 

and Monitor System Health 
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The OPD requirements for Figure 20 follow a similar trend to Figure 19. Their 
aim is to enhance the UAS in sensing and processing. A few minor interface designs are 
suggested to keep the Marines cognizant of the UAS’ status while conducting the initial 
mapping. 

2. Arrange Reconnaissance: Select Emphasis Area(s) 

The Arrange Reconnaissance lA Table’s final task is select emphasis area(s). It is 
broken down into two subtasks: review initial map highlight areas for further refinement 
and query external / joint assets. The former subtask has one capacity and the latter has 
two. Figure 21 depicts these and the OPD requirements. 
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Figure 21. Arrange Reconnaissanee: Select Emphasis Area(s) 
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The OPD requirements in Figure 21 shift back to a Marine focus. This handoff 
from machine to Marine demonstrates that the machine has satisfied the Marine’s 
immediate need for information and is allowing the Marine to process that information. 
This task completes the Arrange Reconnaissance lA Table and the second step in 
BAMCIS. 

C. MAKE RECONNAISSANCE lA TABLES 

The third phase of the Troop Leading Steps work flow is the M in BAMIS: make 
reconnaissance. The tasks associated with UTACC in this phase involve conducting 
detailed mapping, and creating the modified combined obstacle overlay (MCOO). The 
make reconnaissance phase is partitioned into two separate lA Tables. 
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1. Make Reconnaissance: Return, Scan, Alert, Notify, and Monitor 

The first task of the Make Reconnaissance lA Table, conduct detailed mapping, is 
broken down into five subtasks: return to selected emphasis area(s); scan selected 
emphasis area(s); alert team to relevant map information; notify team when near 
completion of mapping; and monitor system health. Figure 22 depicts each subtask, its 
capacities, and associated OPD requirements. 


Figure 22. Make Reconnaissance: Return, Scan, Alert, Notify, and Monitor 
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Due to the similarities in the two tasks, the OPD requirements in Figure 22 are 
similar to those under conduct initial mapping. However, the completion of the detailed 
mapping is necessary for the output of the next task, which is a critical planning factor for 
missions. 
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2. Make Reconnaissance: MCOO 

The second task of the Make Reconnaissance lA Table is the generation of a 
MCOO. MCOOs are broken down into specific overlays, the generation of which 
specifies the subtasks of this task: vegetation; surface drainage; other effects; combined 
obstacles; mobility corridors; and avenue of approach. Sub-overlays can often be broken 
down further into specific features, each of which constitutes a single capacity. This 
breakdown and the corresponding OPD requirements are shown in Figure 23. 


Figure 23. Make Reconnaissance: MCOO 
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The OPD requirements from Figure 23 describe the capacities, or in this case, the 
features of each of the individual overlays that contribute to the greater MCOO. 
Iconography for the interface design is incorporated where appropriate. The color coding 
indicates that the UxVs are gathering data collaboratively. The two systems are heavily 
coordinating activities at this stage of BAMCIS, and it is important that their information 
exchanges be designed seamlessly. The Marines are able to rest and refit during this 
portion of BAMCIS with only minimal requirements to monitor the system’s health and 
the collection of data through the building of the MCOO user interface. The MCOO task 
is the final step in the Make Reconnaissance lA Table and the third step in BAMCIS. 

D. COMPLETE THE PLAN 

The fourth phase of the Troop Leading Steps work flow is the C in BAMCIS: 
complete the plan. The tasks associated with UTACC in this phase involve developing, 
refining, selecting, and submitting mission profiles to higher headquarters for approval 
and assignment of supporting / joint assets. The complete the plan phase of BAMCIS is 
partitioned into seven separate lA Tables. 

1. Complete the Plan: Develop Mission Profiles 

Six of the seven lA Tables correspond to six different subtasks. The subtasks 
relate to the different teaming options available for completion of the mission: Marines 
only; UAVs only; UGVs only; Marines and UAVs only; Marines and UGVs only; and 
Marines, UAVs, and UGVs all working together. 

a. Develop Mission Profiles: Marine Only Profile 

The Marine only profile has four capacities: identify conditions that keep UxVs 
from partnering further, providing a route from assembly area to objective, providing 
imagery of key terrain features along the route and of the objective area, and providing an 
estimated time line. So even though the UxVs may not be partnering fully during this 
profile option, UTACC is still providing valuable information to the Marine only team 
through the interface. 
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Figure 24. Develop Mission Profiles: Marine Only Profile 
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The OPD requirements of Figure 24 speeify inputs that both the Marine and the 
maehine need to provide and step through what that eommunication might look like. The 
eollaboration on the interfaee is aehieved in the form of reeommended routes, imagery, 
video feeds, and adjustable time tables. The color coding schemes displayed in Figure 24 
are all indicative of soft interdependency requirements, which would serve as excellent 
areas for the UTACC design team to focus efforts and resources. All of the capacities are 
things which the system can do with slightly less than one hundred percent reliability or 
where assistance is necessary. 

b. Develop Mission Profiles: UAV Only Profile 

The UAV only profile has four capacities: identify conditions that keep UGV and 
Marines from partnering further; provide areas requiring surveillance; provide the time 
on station per UAV; and provide the time on station with a rotation of UAVs. Even 
though the UGVs and Marines may not be partnering fully during this profile option, they 
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are still providing valuable information to the UAV only team through the interface. 
Figure 25 depicts the capacities and associated OPD requirements. 


Figure 25. Develop Mission Profiles: UAV Only Profile 
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The OPD requirements for Figure 25 are different than those of the Marine only 
and UGV only profiles despite having similar capacities. This may also be evident from 
the drastically different color coding schemes. The UAV only color coding scheme 
indicates that there are some hard interdependency requirements which should be avoided 
or minimized during development. Requirements are limited largely to interface designs 
that allow the human to monitor system health. 

c. Develop Mission Profiles: UGV Only Profile 

As with the UAV only profile, the UGV only profile has four capacities: identify 
conditions that keep UAV and Marines from partnering further; provide areas requiring 
surveillance; provide the time on station per UAV; and provide the time on station with a 
rotation of UAVs. Even though the UAVs and Marines may not be partnering fully 
during this profile option, they are still providing valuable information to the UGV only 
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team through the interfaee. Figure 26 depiets these eapaeities and assoeiated OPD 
requirements. 


Figure 26. Develop Mission Profiles: UGV Only Profile 
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The OPD requirements listed in Figure 26 have a pattern reminiscent of that 
shown in the UAV only profile. However, the soft interdependence in the second row of 
the UGV only profile may prove to be more favorable for UTACC system developers as 
a focus area. The last two rows of the UGV only profile indicate the same hard 
interdependencies, which should be avoided from a development perspective. 
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d. Develop Mission Profiles: Marine and UAV Profile 

The Marine and UAV profile has four capacities: identify conditions that keep 
UGVs from partnering further, determine if route from assembly area to objective will be 
different for Marines and UAVs, identify additional tasks for the UAVs to conduct in 
route to the objective, and identify additional tasks for the UAV to conduct at the 
objective. Even though the UGVs may not be partnering fully during this profile option, 
they are still providing valuable information to the team through the interface. Figure 27 
depicts these capacities and associated OPD requirements. 


Figure 27. Develop Mission Profiles: Marine and UAV Profile 
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Now that the profiles contain two nonhomogeneous entities, the OPD 
requirements from Figure 27 have grown slightly more complicated. Some of the reason 
for the increased convolution is due to the tactical situation and the variable mindsets of 
Marines. For instance, a Marine, under certain circumstances, may wish to have the 
UxVs move with the human team and, in other circumstances, may not want to be even 
remotely close to the system. The requirements of Figure 27 that offer potential for 
developers, again, lie in the second row, as the color coding indicates a soft 
interdependency. The human is locked into providing input in the bottom two rows of 
Figure 27, indicated by the hard interdependency color codes. 

e. Develop Mission Profiles: Marine and UGV Profile 

The Marine and UGV profile has four capacities: identify conditions that keep 
UAV from partnering further, determine if route from assembly area to objective will be 
different for Marines and UGVs, identify additional tasks for the UGVs to conduct in 
route to objective, and identify additional tasks for the UGV to conduct at the objective. 
Even though the UAVs may not be partnering fully during this profile option, they are 
still providing valuable information to the team through the interface. Figure 28 depicts 
these capacities and associated OPD requirements. 
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Figure 28. Develop Mission Profiles: Marine and UGV Profile 
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A color coding pattern emerges again, where the seeond row offers the soft 
interdependeneies, ripe for design and development, followed by hard interdependeneies. 
The OPD requirements in Figure 28 revolve around the same eoneept of offering 
different routes for Marines and UxVs; however, the fact that the UGVs are more 
restricted by terrain than UAVs offers additional challenges. Similarly, these restraints 
limit the tasks that the UGV can conduct in route to or at the objective. Examples are 
listed in the lA Table. 

/. Develop Mission Profile: Marine, UAV, UGV Profile 

The Marine, UAV, UGV profile is the most complex of the teaming options. It 
also has four capacities: determine if route from assembly area to objective will be 
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different for Marine, UGV, and UAV; identify additional tasks for the UGV to conduct in 
route to objective; identify additional tasks for the UAV to conduct in route to the 
objective; and identify tasks for the UAV to conduct at the objective. Figure 29 depicts 
these capacities and associated OPD requirements. 


Figure 29. Develop Mission Profile: Marine, UAV, UGV Profile 
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The OPD requirements for Figure 29 revolve around the Marine’s decision as to 


whether or not to travel together. The three bottom rows of Figure 29 are hard 
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interdependencies that require the Marine to prepare additional tasks for the team 
members. The interface design offers minor possibilities for interdependence despite 
these hard interdependencies. 

2. Complete the Plan: Refine, Select, and Submit Profile(s) 

The final table of the seven Complete the Plan lA Tables corresponds to three 
tasks. These tasks do not require much decomposition, and the relationships of the agents 
are simple. It is, however, important to list the tasks, as they are steps requiring 
documentation in the work flow. Figure 30 depicts these tasks and their OPD 
requirements. 


Figure 30. Complete the Plan: Refine, Select, and Submit Profile(s) 
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The OPD requirements in Figure 30 highlight how information should be 
presented to the Marines. As the Marines review the profiles that were prepared, it is 
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important that profiles support a few interaction mechanisms, which are listed in the 
table. Following the refinement task, the Marine then selects the profile to be executed 
and submits it up to the next higher unit. This task closes out the C in BAMCIS. 

E. ISSUE THE ORDER lA TABLE 

The fifth phase of the Troop Leading Steps work flow is the I in BAMCIS: issue 
the order. There is only one task for this phase, which is able to be captured in a single lA 
Table. The lone task is further broken down into the following subtasks: issue the order 
and conduct three dimensional rehearsals. Figure 31 captures this task and its OPD 
requirements. 


Figure 31. Issue the Order 
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The OPD requirements for Figure 31 reflect that the system, which has performed 
the lion’s share of the work throughout BAMCIS up until now, is entering into its down 
cycle, whereas the Marines are coming off of theirs. Now that sufficient data has been 
collected and analyzed, the planning process nears its end, and Marines prepare to 
execute their mission. The 5PO is issued to ensure that all members are aware of the plan. 
This phase of BAMCIS is completed after rehearsals are conducted with both a 3D 
display via the interface and physical walk-throughs. 

F. SUPERVISE ACTIVITIES 

The final phase of the Troop Leading Steps work flow is the S in BAMCIS: 
supervise activities. This phase possesses five lA Tables consisting of six tasks, 
including: sensor posture, select formation, the task module, maintenance alerts, maintain 
common operational picture (COP), and tactical alerts and cueing. The work compiled by 
Rice et al. (2015) was instrumental in shaping this task decomposition as well as the OPD 
requirements for this phase. A separate column was added to the right of these lA Tables, 
labeled after the Rice et al. (2015) Task Analysis Worksheets (TAW). Also, the capacity 
column of the tables identifies terms that Rice et al. (2015) developed. An abridged 
version of the Rice et al. (2015) description for these terms is listed under the TAW 
column. 


a. Supervise Activities: Sensor Posture 

The first task, with its own lA Table, is sensor posture. This task is distilled down 
into four different postures, each associated with its own capacity: defensive, neutral, 
offensive, and degraded. The descriptions of these postures and their OPD requirements 
are provided in Figure 32. 
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Figure 32. Supervise Activities: Sensor Posture 
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The OPD requirements for Figure 32 delineate a set of outputs that the system 
should provide once the Marine picks a sensor posture. The postures are defined in the 
TAW column. As color coded in Figure 32, the UxVs will be able to choose a posture for 
themselves, requiring Marine approval after the fact. 

b. Supervise Activities: Select Formation 

The next task under the S in BAMCIS is select formation. This task has been 
decomposed into machine only formations, and combined formations. The capacities 
represent those formations which Rice et al. (2015) determined from scratch or in the 
case of a combined formation, adapted from Marine Corps doctrinal publications. In 
either event, the description of the capacity is listed in the TAW column. Along with the 
OPD requirements, these capacities and descriptions are listed in Figure 33. 
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Figure 33. Supervise Activities: Select Formations 
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The OPD requirements for Figure 33 provide a list of outputs that the system 
should have displayed on the interface, as well as further guidance on machine team 
member location within combined formations. The color coding depicts soft 
interdependencies. The robots are capable of moving into position within the formation 
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themselves but could be assisted from either of the other parties and thus increase 
reliability. 


c. Supervise Activities: Task Module 

The task decomposed in the following lA Table is the actual task module, where 
tasks are executed within the work flow. This work is broken down into the following 
stages: departing friendly lines; insertion and infiltration; actions on the objective; and re¬ 
entry of friendly lines. The capacities and OPD requirements are listed in Figure 34. 


Figure 34. Supervise Activities: Task Module 
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The OPD requirements for Figure 34 are derived from soft interdependences as 
indicated with the color coding. The requirements offer simple procedures, design 
mechanisms, a variety of purposes, and even limited cyber considerations. 

d. Supervise Activities: Maintenance Alerts 

The third task under the S in BAMCIS is maintenance alerts and is broken down 
into the following four capacities: fully, partially, and non-mission capable sensor 
statuses (FMC, PMC, NMC respectively), and monitoring fuel levels. These statuses and 
their descriptions—as developed by Rice et al. (2015)—and the OPD requirements are 
listed in Figure 35. 
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Figure 35. Supervise Activities: Maintenance Alerts 
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The OPD requirements for Figure 35 identify that the mission must go on even in 
the face of degraded sensors. Providing the ability to assure Marines of the status of the 
sensors will reinforce their confidence in what the systems are telling them and in the 
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systems as a whole. The color coding indicates that these capacities are hard 
interdependencies that rely on the system to be able to self-diagnose and report. 

e. Supervise Activities: Maintain COP and Tactical Alerts / Cueing 

The final Supervise Activities lA Table has two tasks associated with it: maintain 
common operational picture (COP), and tactical alerts and cueing. The former is broken 
down into sending imagery and data back to the COP and leaders; the latter is broken 
down in the following two capacities: recognizing tactical alert scenarios and recognizing 
cueing scenarios. These capacities and their OPD requirements are listed in Figure 36. 


Figure 36. Supervise Activities: Maintain COP and Tactical Alerts / Cueing 
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The OPD requirements in Figure 36 are formed on hard interdependencies 
between the system components and the Marines. This means that the UxVs are able to 
collaborate and assist one another; however, very little room exists for direct Marine 
feedback. In other words, the Marines will be reliant on the systems to notify them in the 
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event that a specified scenario is tripped into action. These tasks complete the S in 
BAMCIS, and with it, they terminate the BAMCIS process. 

G. CHAPTER SUMMARY AND CONCLUSIONS 

This chapter presented the results of melding the Mission Planning and Execution 
Model with the Coactive Design Model. BAMCIS was the flow of work, or framework, 
around which the Mission Planning and Execution Model was structured. Inserting that 
framework into the lA Tables, which are the design and analysis tool of Coactive Design, 
allowed the author to develop multiple observability, predictability, and directability 
requirements. These requirements provided Marine-specific insight to the UTACC 
developers and highlighted development focus areas that were based on soft and hard 
interdependencies. These suggested refinement areas offer the potential for the greatest 
return on time and resources spent while developing capacities and highlighting areas 
where the Marine is well suited to support the machines. This is often a support 
relationship that is overlooked in developing smart systems. 

1. UTACC Focus Areas: The Five Feedback Categories 

Information is vital to making decisions and the process of gathering and 
disseminating information to a team composed of humans and machines, which each 
collect and require in different forms, is inherently difficult. When conducting the 
traditional task decomposition process associated with the lA Tables, it became apparent 
that the information exchanges between the Marines and machines could be sorted into 
the following five feedback categories: 

• Scoping the Area of Interest 

• Scoping the Area of Uncertainty 

• Platform Capability 

• Sensor Capabilities 

• Time Constraints 

The first two categories are human judgment calls. In other words, the human 
needs to provide feedback to the system in order for it to then be able to make decisions 
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and conduct work. These two categories require the ability to identify the important areas 
and the ability to prioritize how the system approaches work. Within the last three 
categories the system provides feedback to the humans, in order for the Marines to be 
able to make decisions. It is suggested that feedback loops be designed that allow the 
Marine to adjust the parameters of the system and gauge the effectiveness of the 
machines while they are collecting information. The direction of the feedback loops, 
whether it is flowing to or from the Marine or the machine, is of little importance as long 
as there is interplay between both agents. This is the essence of interdependence. 

2. Author’s Marine Perspective Applied to the UTACC Focus Areas 

From the author’s perspective as a Marine infantryman, effectively incorporating 
these feedback loops into the final system should appear intuitive and be as streamlined 
as possible. The following illustration guided the development of the lA Tables in this 
chapter: 


a. Scoping the Area of Interest 

When scoping the area of interest, the machine is in need of the starting location 
of the team and the objective. With these two points an operating box (op box) can be 
established where the machines will scan and conduct work. The size of this op box may 
be too large to efficiently scan or there may be areas within the box that are of no interest 
to the Marine Corps. A visual, electronic map with adjustable parameters and a tool that 
correlates the remaining op box area with the sensor, as well as platform capabilities are 
perceived to be of great use to UTACC. If Marines are able to graphically see this 
correlation as they are adjusting the parameters, they would be able to more accurately 
and efficiently shave the areas requiring scanning. Simply put, moving a boundary a few 
millimeters left or right on a tablet might have the same perceived impact to the Marine, 
whereas to the machine that is required to conduct the scan of the area, it means another 
three hours and two passes overhead with a refueling session. This could be time that the 
team does not possess. This correlation should be presented with a digital clock depicting 
the time required to scan and an icon with a perimeter related to the range of the 
machine’s sensors. This would be a good example of predictability. 
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b. Scoping the Area of Uncertainty 

Scoping the area of uncertainty can be accomplished in a similar manner. Having 
just scoped the area of interest, the Marine is left with a filter over their op box that meets 
their time line. Over the same filter, the Marine should then be permitted the ability to 
prioritize the areas most in need of scanning. Perhaps the area within a few hundred 
meters of the team’s starting position is of little worry and would, then, be prioritized 
low. If the scanning time window shrinks, as planning timelines often do, then the hope 
would be that the highest priority areas would be scanned. 

c. Platform and Sensor Capabilities and Time Constraints 

Other platform and sensor capabilities not discussed in the preceding feedback 
loop discussions may have a substantial impact on the usability of the system. The 
interface should, at a minimum periodically, if not continuously, update with machine 
location. This information should be displayed on the filters mentioned earlier so that 
Marines can gauge efficiency and effectiveness. This information exchange would allow 
them to make adjustments in route. The Marines need to be able to maintain awareness 
about what the machines are doing and how they are performing. To facilitate this end, a 
system health graphic is necessary for the display, visible on the interface. However, as 
with all of these requirements, simplicity is desired. A battery icon with a percentage of 
remaining battery life should be displayed for each machine in the field. A check engine 
light that, when scrolled over, displays the exact malfunction, or warning, is desirable, as 
well. The warning should initially drop down from the periphery of the interface and 
remain for a few seconds, allowing the Marines the opportunity to read it, before 
disappearing and then leave behind just the check engine light. 

This scenario was developed with a few of what the author deems as the most 
important system requirements. The focus of this scenario was the second step in the 
BAMCIS process, arrange for reconnaissance. A comprehensive BAMCIS process 
scenario would become too convoluted and was not attempted. For an inclusive 
understanding of the requirements obtained from this thesis, refer to the individual lA 
Tables. 
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V. SUMMARIZING RESULTS AND RECOMMENDATIONS FOR 

FUTURE RESEARCH 


This thesis has two main impact areas. The first analyzes the merits of whether 
the Coactive Design Process is useful to MCWL in developing the UTACC system of 
systems. The second is using Coactive Design to produce a list of design requirements 
that captured complicated concepts like coordination, collaboration, and cooperation. The 
author focused on interface features and behaviors as the mechanisms for capturing those 
requirements. The third mechanism suggested by Johnson (2014), not taken into account 
here, was control algorithms and is better left to the UTACC software and systems 
engineers. The author’s personal experience as a Marine Corps infantry officer was also 
taken into account, not only when shaping these design requirements but also in 
providing perspective to the UTACC team and stakeholders. 

A. SUMMARY OF RESULTS 

As Johnson (2014) stated “Coactive Design breaks with traditional human- 
machine design approaches by focusing on effective management of interdependencies 
verses focusing on autonomy.” It has a foundation in systems engineering and as an 
iterative design and development method is well suited to meeting the demands of a 
future military system where requirements will change throughout the development life 
cycle. 


1. General Comments 

Communication is key to any relationship. The processes for how information is 
shared so that decisions can be made vary widely from relationship to relationship and 
only increase in complexity with the addition of individuals or agents. Within the 
construct of human-machine teaming, humans and machines speak in different languages 
and require different pieces of information, often times in formats unusable by the other 
agent. The UTACC system’s interface is the tool by which the human is able to 
communicate with the robots and vice versa. It is in this medium that information is 
pushed and pulled by both human and machine components for planning, rehearsing, and 
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executing a mission. The UTACC specific lA Tables address many elements that need to 
be incorporated when developing the interface in order to maintain the interdependencies 
between the Marines and machines. 

The Marine Corps Troop Leading Steps, BAMCIS, were used to structure the 
work flows analyzed under the Coactive Design lens. By using this concept, of which all 
Marines are familiar, the SoS is able to integrate more seamlessly into the ways Marines 
already gather information and act. This reduces the amount of system learning required 
of organizations that typically accompanies adoption of new technology. Additionally, it 
accelerates the time with which Marines will begin to experiment with the technology 
and use it in creative and beneficial ways other than those in which it was originally 
intended. Therefore, creating a system that complements the existing Marine Corps 
framework is critical. 

2. Benefits of Coactively Designing UTACC 

Coactive Design offers three distinct benefits to UTACC as it seeks to grow in 
size and scope over a timeline that is appealing to Department of Defense (DOD) 
acquisition officials. These benefits are (1) DOD familiarity, (2) a resilient system, and 
(3) focusing efforts in a time and resource constrained development environment. They 
are elaborated on below. 

a. Capitalizing on DOD Familiarity with the Coactive Design Approach 

Coactive Design is an emergent human-machine system design method that 

gained the attention of the Department of Defense (DOD) during two recent 

demonstrations. The first demonstration was the 2013 Defense Advanced Research 

Projects Agency’s (DARPA) Virtual Robotics Challenge (VRC). There, Coactive Design 

author. Dr. Matthew Johnson, working with the Florida Institute of Human Machine 

Cognition (IHMC) earned a commanding first place out of 126 potential competitors. The 

second demonstration was the 2015 DARPA Robotics Challenge (DRC), where IHMC 

earned top honors and second place out of the 24 competing teams. Of note, both IHMC 

and the first place winner of the 2015 competition earned the same point score during the 

competition. Task completion time was chosen as the tie breaker, and the winning team’s 
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creativity in working around the bipedal constraints of the competition during a few of 
the prescribed challenges allowed it to shave enough time to pull into the lead. IHMC’s 
ability to complete this task as a bipedal robot demonstrated a level of mastery of a very 
complicated robotic function that was lacking in the winning teams prototype. For these 
reasons, Coactive Design is, at the time of this writing, being explored by DARPA for an 
experimental, enterprise wide. Pilot’s Assistant Program. Further investing in Coactive 
Design for use with UTACC would capitalize on the DOD familiarity with it, and would 
align with the Marine Corps’ Expeditionary Force 21 (EF21) strategic initiative to remain 
on the cutting edge of technology. 

b. Flexibility over Brittleness 

The second advantage offered by Coactive Design to UTACC is flexibility. 
UTACC is a SoS that will need to operate in a complex environment where uncertainty 
will be highly prevalent. Being able to perform the same task in many different ways is 
what lA Tables help identify, rather than building the system to work under 
circumstances that may be hard to attain in real life. Eurthermore, when a system is 
designed with too much dependence on the robot to operate autonomously, and without 
any alternative pathways for the work to be completed, the system is said to be brittle. 
Coactive Design targets this brittleness by considering multiple pathways through a task 
that take advantage of the unique capabilities that both humans and machines bring to the 
team. As a result, when one alternative fails, the mission may continue on. 

As Dr. Johnson (2014) often stated, “In robotics, if you do not plan to fail, you are 
failing to plan.” When placing robots into a teaming environment, designers must 
consider uncertainty and build in the capabilities to respond to unexpected events. This 
requirement is addressed by designing resilience into the system, which brings about the 
third advantage offered by coactively designing UTACC. 

c. Developing Efficiencies in Design and Development 

The Coactive Design approach to developing UTACC provided an excellent cost- 

benefit study of development choices during IHMC’s preparation for the DRC (Johnson, 

2014). IHMC had one and a half years to develop their humanoid robot for the 
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demanding and wide ranging challenges encountered in the DRC. With a limited budget, 
small time window, and host of issues designed to instill a sense of uncertainty over the 
challenges, IHMC needed a means of focusing their effort on high reward development 
issues. UTACC would benefit in a similar fashion as it is pressed to develop a resilient 
teaming focused SoS on budget despite a host of software engineering timelines. 

As indicated in the UTACC lA tables, UTACC engineers should seek to avoid 
developing highly “autonomous” recognition capabilities where a simple cue to a Marine 
equipped with a superior sense of situational awareness could quickly approve or dismiss 
a potential threat or target. Just as the IHMC team saved a lot of time and money by not 
investing in complex perception and planning, so too could UTACC (Johnson, 2014). 
Instead UTACC should focus resources on enabling the human to be an effective 
teammate, much as Johnson (2014) did during the DRC. This thesis has argued that the 
best ways of enhancing the Marine’s effectiveness is with the presentation of information 
collected by the team, through (1) the user interface and (2) designing for multiple 
alternatives in task completion. Eliminating the 100 percent solution (e.g., the ends of the 
autonomy spectrum: full autonomy or full teleoperation) eliminates the hardest problems. 
The Coactive Design method engineers systems that exploit synergy between systems 
and humans—which is what teaming is all about. 

B. SUGGESTED UTACC FOCUS AREAS BASED ON COACTIVE DESIGN 

When conducting traditional task decomposition processes associated with the lA 
Tables it became apparent that the information exchanges between the Marines and 
machines could be sorted in the following five feedback categories. 

• Scoping the Area of Interest 

• Scoping the Area of Uncertainty 

• Platform Capability 

• Sensor Capabilities 

• Time Constraints 
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The first two categories are human judgment calls. In other words the human 
needs to provide feedback to the system in order for it to then be able to make decisions 
and conduct work. These two categories require the ability to identify the important areas 
and the ability to prioritize how the system approaches work. Within the last three 
categories the system provides feedback to the humans in order for them to be able to 
make decisions. It is suggested that feedback loops be designed that allow the human to 
adjust the parameters of the system and gauge the effectiveness of the machines while 
they are collecting information. The direction of the feedback loops, whether it is flowing 
to or from the Marine or the machine, is of little importance, as long as there is interplay 
between both agents. This is the essence of interdependence. 

C. RECOMMENDATIONS FOR FUTURE RESEARCH 

This work was only the initial step in developing a coactively designed UTACC. 
It has analyzed the merits of pursuing this specific design approach and recommended 
that it be adopted for the duration of the program. Furthermore, this thesis has made 
recommendations on initial system requirements and bridged much of the previous 
concept development work with the tool that achieves these requirements, the lA Table. 
As an iterative design process, truly capitalizing on Coactive Design requires investing in 
it over the long term, which may be achieved through the following: 

1. System Engineering in the Program Organizational Structure 

The first recommendation to sustaining the momentum brought about by this 
thesis is to incorporate a coactive designer into the existing UTACC program’s 
organizational structure. Figure 37 is a recommended organizational chart that 
graphically depicts the administrative and operational relationships such a Coactive 
Designer would need in order to ensure proper utilization. 
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Figure 37. Coactive Designer in the Program Organizational Structure 



As with all software design projects, the designer and developer should be in 
constant conversation. Such conversation is not characterized by one role being 
subjugated to the other. Rather, mutual respect for the insights and contributions of each 
respective position must be acknowledged. It is of critical importance that the 
conversations and interactions of these two positions be physically joined to the greatest 
extent possible. This is not limited to merely working in the same building, although that 
would appear a bare minimum. The designer and developer should occupy the same work 
space, be entwined in every phase of the project from concept development, requirement 
generation, programming, testing, and evaluation. Doing so will only enhance the 
system’s flexibility, benefitting the overall project resiliency. 

2. Maintain Momentum by Overlapping Turnover among Designers 

As with any iterative design, the true insights come about after the designer and 
developer exchange perspectives. It was observed by the author that after holding a team 
meeting, where the Coactive Design results were shared with the normally physically 
disparate project team members that design potentials were not only realized but were 
actually improved upon. Given the physical isolation of the project’s team members, at 
least one other gathering of the minds should be held where the author could conduct a 
proper turnover of knowledge and experience with his replacement and more aptly 
guarantee a smooth transition among designers. This turnover would greatly reduce the 
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amount of time it would take to get a new designer familiar with previous work 
conducted and could alleviate many of the issues that would arise should that new 
designer not have background working in the Marine Corps infantry. 

3. Designing beyond the Demonstrations 

This thesis has made recommendations for where UTACC should focus its 
limited efforts within the many design requirements identified in the UTACC lA tables. 
Achieving all of them will require that multiple drafts of lA tables be tied to 
experimentation and the prescribed evaluation of change processes with accompanying 
feedback loops into the identification processes. 

The set of scoped recommendations served the purpose of meeting a 2016 
UTACC demonstration, which extended an earlier proof of concept demonstration. Under 
tight time and resource constraints, the UTACC project team used the UTACC lA Tables 
to focus their efforts. The team selected only a few of the requirements identified. When 
moving beyond this second iteration demo, it is recommended that future Coactive 
Design selection and implementation periods be implemented. During these periods the 
team should take a look at incorporating and expanding the remaining requirements 
found within the lA Tables of this thesis and explore new areas as UTACC’s scope 
grows. 


4. Building a Final Resilient System 

Alternative teaming options are a part of this thesis. The UTACC Coactive 
Design lA Tables specify three generic teaming options for every subtask that is 
specified. The next step, beyond the scope of this thesis, is to depict the multiple 
pathways through a given alternative. Figure 38 graphically depicts what this would look 
like. 


81 




Figure 38. The Pathways through an lA Table’s Alternative Teaming Options 


R+H 


H+R 
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Sources; Johnson, M., Shrewsbury, B., Bertrand, S., Calvert, D., Wu, T., Duran, D., 
Stephen, D., Mertins, N., Carff, J., Rifenburgh, W., Smith, J., Schmidt-Wetekam, C., 
Faconti, D., Graber-Tilton, A., Eyssette, N., Meier, T., Kalkov, L, Craig, T., Payton, N., 
McCrory, S., Wiedebach, G., Layton, B., Neuhaus, P., & Pratt, J. (in press). Team 
IHMC’s lessons learned from the DARPA robotics challenge: Finding data in the rubble. 
Journal of Field Robotics. 


Figure 38 is an expanded lA Table taken from IHMC’s lessons learned from the 
DRC. It adds several extra steps to the analysis of teaming alternatives (represented in the 
right half of the figure). A detailed description of this process is beyond the scope of this 
thesis. The important takeaways include: the columns identifying which component will 
perform work; the sub-columns to the components that specify the design requirement, 
which controls the capacity; the ability to list multiple components as able to perform 
work; the ability (through color coding) to depict the range of a components’ ability to 
perform work; and a means of physically and logically tracing multiple paths through the 
workflow to completion of the task. 

Tracing the alternative pathways through a task allows developers to more 
accurately identify where the soft interdependencies lie, and thus where development 
efforts should be focused. Furthermore, mapping out these multiple pathways, provides 
the Marine-machine team with alternative ways of recognizing and handling the 
unexpected. The teamwork infrastructure’s flexibility is supported with a multitude of 
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interdependent relationships. Naturally, these alternatives should be a part of the training 
regime designed for UTACC. 

5. Three Selling Points: Dull, Dangerous, and Dirty 

When deciding on future requirements to pursue, or when creating new ones, 
there are three points that will further help to direct efforts. 

• What task is difficult to do? 

• What is dull or boring to do? 

• Is the system annoying or difficult to use? 

When designing H-M systems, the goal is to bring the human to the things that 
they should be focusing on. The machine should be mapped to the human and not the 
other way around. This is easily stated but often becomes difficult to put into practice. 
UTACC aims to reduce the cognitive load of the human with respect to controlling the 
system but does not seek to eliminate the cognitive load entirely. The system 
requirements provided in this thesis focus on keeping the greater cognitive or judgment 
calls with the human so that they are not devoting all of their cognitive abilities to staring 
down a soda straw or completing basic mechanistic manipulation. The goal is not to 
remove the human operator from the equation but to reduce difficulty, remove dullness, 
and refocus towards accelerating, when necessary, the decision loop. 

6. Levels of Information 

The concept of maintaining a common operational picture (COP) where 
information from UTACC not only exists and can be passed within the Marine-machine 
team but integrates into the situational awareness of war fighters at all levels is appealing. 
This was a future research concept listed in the Rice et al. (2015) thesis as well. It merits 
re-mentioning for its relevance with big data issues, deciphering which data elements get 
passed, and to which level of command they ought to be delivered. 
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7. 


Number of Marines within the UTACC Team 


This thesis’ primary contribution, the lA Tables, simplified the number of agents 
analyzed down to one Marine, one unmanned aerial vehicle, and one unmanned ground 
vehicle. Marines do not operate as individuals in the field. Therefore, it is important to 
define whether UTACC is being designed to work with only one human within a unit or 
will all the members of a small tactical unit in order to effectively operate the SoS. If 
more than one human is the answer then further analysis is needed as to whether all of the 
Marines get the same interfaces, have the same abilities to push information to the 
machines, and make decisions about what to have the machines do. Perhaps the solution 
rests with a large, interactive tablet display for the unit leader with full administrative 
permissions and smaller interfaces that serve in a display only mode. 

8. Emissions Protections 

Due to the fact that the machines are sending large amounts of data and 
continuously communicating with the other members of the team and building a COP 
across all the levels of command, the potential of being detected by an adversary comes 
into play. It is theorized that some of the burden of reporting would be relieved due to 
this unsolicited communication, relieving the Marines of their need to pass position 
reports and elements of situation reports, as examples. However, it is not foreseen 
whether or not additional and unintentional reporting would be caused by this SoS. 
Further research is needed to develop electronic detection and protection procedures and 
their effects on reporting. 

9. Authority among Machines 

Just as other Marines must pick up the slack when an individual Marine is taken 
out of the fight in the middle of a mission, so too must the other machines pick up the 
slack when an individual machine goes down. The machines, especially when operating 
alone in the field, conducting remote mapping, would serve as easy targets. Additionally, 
they have to battle environmental and mechanical issues. Developing a rotating 
distribution of authority among the machines so that no head can be metaphorically 
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chopped off is of critical importance. Similarly, by sharing a COP, the data gathered by 
one machine will not be lost should it go down. 

10. Ethics of Robotics Use in Defining Military Missions 

Developing robotic systems for use within the military brings to light many issues 
that are of little or no concern in the public sector. The incorporation of lethal and non- 
lethal weapons, targeting systems, and invasive surveillance technologies are potential 
progressions for any military robotic system. Singer’s (2009) book. Wired for War, 
discussed how innovative technologies often develop unanticipated roles as users gain 
familiarity and confidence with their use. Brutzman et al. (2016) identified many key 
considerations and constraints that helped them define ethical military missions and their 
execution. As the UTACC system is developed, incorporating a framework similar to 
Brutzman’s et al. (2016) could identify several of these potential missions. 

11. Recommended UTACC Coactive Design Focus Areas 

The UTACC design requirements presented in this thesis focus largely on 
graphical user interface design. Designing this series of interfaces with a BAMCIS 
backbone capitalizes on pre-existing Marine training and thought processes during the 
planning and execution phases of a mission. Incremental development of theses interfaces 
is suggested. It is essential that both the Marine-user and coactive designer are included 
during the multiple iterations of testing and evaluation. Figure 39 provides 
recommendations for the first increment of coactively designed interfaces. 
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Figure 39. First Increment Interface Elements 


BAMCIS 

Essential First Increment Coactively Designed Interface Elements 

B 

5 paragraph order (5PO) interface 

A 

Map (visually correlates adjustable op box parameters into time and space 

considerations) 

M 

Modified combined obstacle overlay (MCOO) 

C 

Mission profile options 

I 

3D rehearsals 

s 

Ability to direct the machines as the mission deviates from the plan (includes 
formations, immediate re-tasking, sensor postures, etc.) 


The underlying goal of these interfaces is to translate information between the 
human and machine domains so that it may be of use to both of them. These design 
features make high level concepts like collaboration for human-machine teaming 
achievable under the UTACC construct. 

D. CHAPTER CONCLUSION 

Developing a resilient Marine-machine system capable of operating under various 
operational contexts and able to assist with the multitude of missions required of today’s 
forces is no small task. The core issue surrounding the task relates to getting Marines and 
machines to work together. Coactive Design was built upon the concept of 
interdependence. Only after one understands the importance of how these 
interdependencies affect the teamwork infrastructure can one successfully build the 
bridge between the two agents. 
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